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Summary 


A rrarc  <fc/r<z  is  a form  for  representing  segments  of  computation.  A state  delta  is 
a first-order  predicate  w.nich  takes  a precondition,  a postcondition,  a modification  list 
and  an  environment  list.  The  semantics  of  a state  delta  are  "if  the  machine  is  in  a state 
which  satisfies  the  precondition,  it  will  eventually  reach  a state  which  satisfies  the 
postcondition,  and  it  will  do  so  without  modifying  any  locations  except  (possibly)  those 
listed  in  the  modification  list." 

It  is  intended  that  state  deltas  be  used  in  a proof  system  in  which  predicates 
which  describe  the  current  state  of  a machine  are  cross-referenced  according  to  the 
locations  containing  values  used  in  each  predicate  In  such  a system,  reasoning  about 
the  forward  progress  of  a machine  may  be  carried  out  by  successive  application  of  state 
deltas  Application  of  a state  delta  is  legal  if  the  precondition  is  true  of  the  current  state 
and  if  none  of  the  locations  in  the  environment  list  has  been  changed  since  the  state 
delta  was  entered  into  the  system.  After  these  checks  have  been  made,  application 
consists  of  deleting  a!!  predicates  cross-referenced  to  any  of  the  locations  in  the 
modification  list  and  adding  the  predicates  in  the  postcondition  to  form  a new  current 
state 


If  some  of  the  locatics  in  the  machine  being  modeled  hold  arrays  or  lists,  the 
ctoss  referencing  part  of  the  proof  system  may  provide  for  predicates  to  be  attached  to 
components  Gf  the  locations  If  the  proof  system  further  allows  for  names  to  be  given  to 
individual  components  of  locations,  it  is  entirely  possible  for  different  predicates  to 
depend  upon  the  same  values  under  different  names  Under  these  circumstances,  it  is 
necessary  to  keep  track  of  all  of  the  overlap  conditions  possible  among  a set  of  named 
locations  In  most  cases  of  interest,  a graph  structure  with  two  types  of  nodes  can  be 
employed  to  represent  all  of  the  possible  overlaps,  and  this  graph  can  be  searched  quite 
efficiently  whenever  the  current  state  is  to  be  modified. 

A small  proof  system  has  been  built  along  these  lines  and  has  been  used  to  prove 
the  correctness  of  a slice  of  the  code  in  the  IMPs  in  the  ARPANET.  This  code 
allocates  a buffer  off  the  free  bufferhst  and  uses  indirect  addressing  and  other  pointer 
techniques  to  accomplish  its  task  Representing  the  allocation  of  storage  and  following 
the  trail  of  the  pointers  fully  illustrates  the  utility  of  the  graph  system  for  representing 
storage  relationships 
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1.  Introduction 


I have  been  interested  in  applying  formal  verification  techniques  to  real 
programs.  What’s  a "real"  program?  One  whose  reason  for  being  written  is  to 
accomplish  some  computational  task  and  not  solely  to  serve  as  an  example  for 
verification  reseat  di. 

I chose  the  code  for  the  IMPs  in  the  ARPANET  as  a real  program  to  study.'*  For 
the  picsent  discussion,  it  is  sufficient  to  know  that  the  code  consists  of  about  10,000 
instructions  (including  load-time  constants),  runs  on  a Honeywell  316,  which  is  a rather 
standard  minicomputer,  and  is  written  in  the  assembly  language  for  the  machine.  Its 
purpose  is  to  ship  messages  around  the  network  from  source  "hosts"  to  destination  hosts. 

When  1 began  looking  into  the  IMP  code,  I hoped  that  existing  theory  and 
techniques  would  be  sufficient.  My  task  would  be  only  to  extract  the  relevant  details 
fiom  the  IMP  code  and  submit  them  to  an  existing  verification  system.  1 was  prepared, 
of  course,  to  supply  all  of  the  assertions  that  might  be  required,  define  the  concepts  and 
terms  specific  to  the  IMP  code,  and  write  some  sort  of  preprocessor  to  transform  the 
machine  language  (or  its  assembly  level  representation)  into  some  more  pleasant  form 
consumable  by  existing  verification  systems. 

It  didn't  take  long  to  find  out  this  approach  wouldn’t  work. 

Two  classes  of  problems  emerged  First,  existing  verification  systems  are  still  in 
an  early  stage  of  development  Verifying  a program  of  any  sire  would  requite  both 
extension  of  the  existing  system  to  handle  primitive  operations  such  as  anding  and 
oring  of  bitstrings  and  extensive  interactive  direction  to  drive  the  system.  Were  these 
the  only  problems,  the  right  course  would  have  been  to  help  extend  an  existing  system. 

The  problems  in  the  second  class  arc  more  fundamental  1 could  not  find  a way 


^ Tlir  ARPANET  is  ilrsi'iihol  by  Larry  Hohcris  ami  harry  esslcr  in  "Computer 
Networks  lo  Achieve  Resource  Shai nip",  Proceedings  of  the  AMPS  Spring  Joint  Coniputcr 
Conference , Vol.  Mt,  Ainrnr.ni  Krileralioii  of  Itifoi m.il ion  Pioeessmp  Societies,  Monlvale,  New 
Jersey,  1970,  pp.  SIT-519.  for  a description  of  the  IMP  program,  see  "The  liuerfaee  Mcssapc 
Processor  for  llto  AKPA  Computer  Network",  by  Frank  Heart,  ct  at.,  pp.  SSI -567  in  ihc  same 
volume. 
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to  map  the  following;  facts  and  practices  pertaining  to  the  IMP  code  into  the  formalisms 
accepted  by  existing  verification  systems 

Indirect  addressing,  computed  branches  and  program  modification  are  used 
extensively. 

Pointers  arc  used  extensively  to  manage  space  and  eliminate  expensive 
copying  of  data  from  one  location  to  another. 

All  of  the  code  and  all  of  the  data  share  a common  residence  - the  memory 
of  the  machine.  Any  proof  of  correctness  of  the  system  needs  to  include  a 
proof  that  data  and  programs  assumed  to  be  separate  from  each  other  are 
indeed  disjoint  and  do  not  clash. 

The  code  consists  of  a number  of  routines  driven  by  interrupts  and 
operating  concurrently.  Some  of  the  interactions  are  timing-dependent, 
slowing  down  or  speeding  up  the  processing  time  for  some  of  the  routines 
could  cause  the  system  to  fail. 

Why  aic  these  aspects  of  the  IMP  code  unacceptable  to  existing  verification 
systems?  Current  efforts  to  build  piogram  verification  systems  are  based  on  Floyd’s 
approach. r>  In  these  systems,  a program  is  represented  in  a flowchart  form  and 
augmented  with  assertions  which  relate  current  values  of  the  various  program  variables. 
The  assertions  are  then  combined  with  tl.'  program  text  to  produce  a set  of  lemmas  - 
called  verification  conditions  - to  be  proven.  Simplification  and  theorem-proving 
programs  are  then  used  to  prove  each  of  the  lemmas.  When  all  of  the  lemmas  have 
been  pi  oven,  the  piogram  is  guaranteed  to  be  consistent  with  the  assertions  embedded 
in  the  program,  m particular,  if  one  of  the  assertions  is  attached  to  an  entry  arc  and  one 
to  an  exit  arc,  then  this  pair  of  assertions  forms  the  input-output  assertions  for  the 
program.  Systems  built  along  these  lines  have  a number  of  limitations. 

Generation  of  the  verification  conditions  is  completely  automatic  and  thus 
depends  upon  a purely  syntactic  analysis  of  the  program  for  programs 


■’  Tin  ilimn  i«.  on i lined  in  "Ass*pninp  Mcainiij's  in  1‘ioprains,"  l»y  Roherl  W.  Floyd, 
pi  mini  in  Mathematical  Aspects  of  Computer  Science,  Yol  XIX,  I'inerrihnps  of  Symposia  in 
Applied  M.u lirnui irs,  Amrrir.in  Mai  lictnal  icai  Society,  I’lnvidencr,  Itliodc  Island,  19(i7,  pp.  19- 
A lypnal  svslini  Imsed  on  tins  ilirory  lias  |>rrn  nnplrmi tiled  mule e die  diteeiion  of  Ralph 
I on, Ioii  "An  liiici.ichvc  Pinpiain  Verifieai ton  System,”  hy  Donald  I.  Good,  Ralph  l.omlon  and 
W.  W . Illedsor,  pn  1.1  idicd  in  It  IF.  7 ransactions  on  Software  Lnptnecrinp,  Vol  SK-1,  No.  1, 
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possible.  I lowever,  for  programs  written  at  the  assembly  level  or  in  rich 
lang napes  winch  permit  program  modification  and  computed  branches, 
determination  of  the  paths  must  be  combined  with  the  proof  process  itself 
Another  facet  of  the  same  problem  is  that  the  programmer  may  want  to 
analyze  his  program  in  terms  of  execution  sequences  which  do  not 
correspond  to  successive  values  of  the  program  counter.  Table-driven  or 
interpretive  systems  may  look  like  reasonably  simple  repetitive  loops  if  only 
the  apparent  flow  of  control  is  followed,  whereas  the  actual  complexity  of 
the  program  may  be  buried  in  the  "data". 

No  distinction  is  made  between  the  value  stored  in  a program  variable  and 
the  name  of  the  program  variable  itself.  Without  this  distinction  it  is 
unclear  how  to  represent  the  state  of  affairs  for  programs  using  pointers, 
indirect  addressing  and  related  practices. 

Arrays  are  usually  treated  as  closely  as  possible  as  simple  variables  so  that 
assignment  to  a component  of  an  array  is  considered  to  have  changed  the 
value  of  the  entire  array.  As  a consequence,  every  fact  known  about  the 
ai  ray  must  be  rcdcrivcd  after  an  assignment  to  any  part  of  it.  T his  is 
particularly  disastrous  for  verification  of  machine  language  programs;  all  of 
memory  is  one  array! 

Tlicic  are  simply  no  provisions  at  all  for  treating  timing-dependent  code. 

In  addition  to  these  fundamental  limitations,  there  aie  also  some  engineering 
considerations  that  materially  limit  the  utility  of  existing  systems. 


'Crimination  is  one  of  the  most  common  properties  requiring  verification. 
Unfortunately,  l loyd’s  theory  treats  termination  quite  separately  from 
attainment  of  correct  values.  A completely  separate  set  of  assertions  and  a 
separate  proof  arc  required,  approximately  doubling  the  work.  This  cost 
has  not  yet  been  passed  on  to  the  user,  however,  because  the  implemented 
of  vciification  systems  have  not  yet  built  the  additional  machinery  to 
handle  termination. 

T he  separation  of  the  verification  process  into  two  distinct  stages, 
generation  of  verification  conditions  and  proof  of  the  verification 
conditions,  means  that  much  of  the  structure  of  the  program  i . inaccessible 
during  the  proof  process.  In  my  view,  this  is  an  unnatural  separation 
which  will  tend  to  make  verification  unnecessarily  difficult  in  practice 
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Cunent  practices  require  that  the  programmer  write  down  all  facts  relating 
to  the  current  state  in  every  assertion.  Since  an  assertion  is  required  for 
every  loop,  the  programmer  will  frequently  need  to  copy  facts  which  are 
inelevant  to  the  loop  but  which  must  be  brought  forward  across  the  loop. 

I or  example,  jf  one  section  of  the  program  sets  the  value  of  KIO  to  be  zero, 
and  the  next  section  uses  a loop  to  clear  an  array  but  docs  not  change  F00 
in  the  process,  the  assertion  attached  to  the  loop  for  clearing  the  array  must 
nevertheless  include  a clause  stating  that  the  value  of  F00  is  zero. 

One  possible  response  is  to  suggest  that  the  IMP  code  is  a poor  choice  for 
verification  and  that  only  programs  which  satisfy  a particular  set  of  constraints  should 
be  considered  for  verification.  This  point  of  view  is  usually  espoused  under  the 
"structured  programming"  label  or,  more  recently,  under  the  "quality  softwate"  label. 

In  general,  I can  agree  that  structuring  techniques  should  be  used  whenever 
possible  and  I am  a strong  proponent  of  higher-level  languages  and  strong  conventions, 
provided  the  languages  and  conventions  do  not  interfere  with  the  accomplishment  of  the 
primary  task.  In  many  cases,  however,  languages  for  programming  an  important 
application  on  a particular  machine  either  do  not  exist  or  else  impose  intolerable  time  or 
space  limitation.  In  such  cases,  assembly  language  or  other  loose  forms  of  code 
generation  arc  essential. 

More  to  the  point,  perhaps,  is  a strong  feeling  on  my  part  that  the  essentials  of 
piogram  verification  need  not  be  tied  to  any  particular  language.  In  my  own  experience 
as  a programmer,  1 find  that  there  is  only  a little  variation  in  the  analyses  of  (say)  LISP 
programs  versus  machine  language  programs. 

Finally,  fioin  a common  sense  viewpoint,  the  IMP  code  is  not  very  complex.  Most 
competent  programmers  would  find  it  possible  to  learn  the  code  and  relate  observed 
behavior  of  the  IMP  to  the  structure  and  content  of  the  code. 

As  a consequence,  I prefer  to  take  programs  like  the  IMP  program  as  fixed  points 
on  the  landscape  and  ask  whether  there  are  techniques  possible  for  analyzing  them  and 
ptoving  their  piopcrtics 

This  line  of  inquiry  has  yielded  the  following  results. 

A new  fomi  for  representing  a segment  of  computation  has  been  invented. 

The  new  form  is  a state  delta  (5>D).  The  essential  components  of  a SD  are 
a precondition,  a postcondition  and  a modification  list.  The  pre-  and 
postconditions  ate  picdicatcs  on  the  machine's  s'atc  vector  and  the 
modification  list  is  a set  of  names  ol  components  of  the  state  vector.  The 
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semantics  of  a state  delta  is  “if  the  machine  is  in  a state  which  satisfies  the 
precondition,  it  will  eventually  reach  a state  which  satisfies  the 
postcondition,  and  in  ike  course  of  ike  intervening  computation,  only  the 
places  listed  in  the  modification  list  may  be  changed."  1 he  modification  list 
is  the  mechanism  which  relieves  the  pre-  and  postcondition  of  the  burden 
of  copying  static  information  forward  through  a proof. 

State  deltas  arc  first-order  predicates  in  their  own  right,  and  a proof  theory 
has  been  developed  which  provides  the  logical  machinery  for  using  state 
deltas  in  proofs  and  proving  new  state  deltas.  The  proof  theory  is  a direct 
extension  of  the  theory  in  Kalish  and  Montague’s  treatment  of  first-order 
predicate  calculus  with  identity  and  definite  description^’  and  contains  two 
new  inference  rules  One  of  these  rules  provides  the  basis  for  forward 
reasoning  through  the  sequential  parts  of  a program.  The  other  provides 
for  combination  of  state  deltas  which  cover  alternative  paths.  No  new 
inference  rules  arc  required  for  loops;  the  usual  forms  of  mathematical 
induction  arc  completely  adequate. 

One  of  the  intended  uses  for  state  deltas  and  the  new  proof  machinery  is  to 
provide  rigorous  proofs  of  correctness  of  code  which  involves  indirect 
addressing  and  list  structures.  T his  requirement  led  to  an  understanding  of 
the  role  of  phccnamcs,  i c.,  names  of  components  of  the  state  vector.  In 
most  theories  used  in  piogram  verification,  these  names  are  fixed  and 
represent  disjoint  components,  l’art  of  the  theory  developed  here  provides 
machinery  for  referring  to  overlapping  components  of  the  state  vector  and 
for  using  proof  variables  as  well  as  constants  to  refer  to  parts  of  the  state 
vector,  in  essence,  all  possible  overlap  relationships  among  the  placcnames 
in  use  must  be  known  A compact  form  for  representing  this  information 
and  an  extremely  efficient  method  for  searching  the  representation  to  find 
the  most  highly  intersecting  set  of  places  has  been  developed 

r.ascd  on  the  proof  theory  developed,  a trial  verification  system  has  been 
developed  and  tested  The  system  is  a blend  between  a proofchccker  and  a 
symbolic  execution  system.  State  deltas  ate  used  to  pi  ogress  forward 
through  a computation  symbolically  and  a complete  record  is  kept  of  the 
effects  One  of  the  design  goals  for  this  implementation  was  that  the  cost  of 
making  a single  step  should  be  nearly  independent  of  the  sire  of  the  state 
description  at  any  point  This  goal  was  only  partly  realized,  but  the 
difficulties  became  clear  and  provide  direction  for  future  implementations. 


^ Don. i M kaltsli  .uni  Kirlianl  Monlapuc,  LOGIC:  Techniques  of  Formal  Reasoning, 
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As  pait  cjI  iliv  txpu nmntation  with  the  vtnficahtm  systa-Tn,  The  operation 
of  the  310  was  coded  into  a set  of  state  deltas.  This  led  to  an  exploration  of 
other  forms  of  description  of  machine  behavior,  and  an  experiment  was 
carried  out  to  translate  machine  descriptions  in  L.ell  and  Newell’s  ISP 
notation  into  state  deltas  This  translation  was  successful,  but  an  excessive 
immbei  of  slate  deltas  were  generated  I developed  an  alternative  scheme 
for  ti ansl.it mp,  ISP  descriptions  into  far  fewer  state  deltas,  but  have  not 
implemented  this  new  scheme.  One  byproduct  of  the  experimentation  with 
ISP  has  been  a set  of  interactions  with  other  researchers  using  machine 
descriptions  for  simulation,  code  generation,  hardware  design  and  other 
apphe 04OU5  Out  o!  these  iufctacmaus  there  is  wwiwj  sufficient 
experience  to  design  a machine  description  language  which  is  rigorously 
defined  and  suitable  for  a wide  spectrum  of  applications. 

f inally,  the  system  was  used  to  prove  the  correctness  of  a tiny  section  of  the 
IMl’  coue  I his  section  ot  the  IMP  code  allocates  a butter  trom  a tree 
storage  list.  The  pioof  of  correctness  of  this  section  of  the  IMP  code 
required  specification  of  the  list  structures  used  in  the  IMP  code  and 
provides  a blueprint  for  verifying  related  implementation  of  other  list 
processing  code  The  proot  itself  is  quite  long  and  reflects  the  primitive 
nature  of  the  verification  system.  As  may  be  expected,  however,  the  tedium 
of  preparing  a long  pioof  of  very  small  steps  has  provided  substantial 
guidance  for  future  improvement  of  the  verification  system 

In  addition  to  the  limitations  mentioned  above,  the  present  work  makes  essentially 
no  contribution  toward  an  understanding  of  concurrency  and  timing.  The  concept  of 
keeping  track  ul  what  may  be  changed  between  two  points  11s  time  teems  to  be  necessary, 
but  a much  stronger  formalism  will  need  to  be  cieatcd  to  represent  the  interactions 
among  multiple  processors. 

These  results  arc  elaborated  in  the  succeeding  chapters.  Chapter  two  contains  the 
detailed  formulation  ol  state  descriptions  and  state  deltas.  Chapter  three  describes  the 
structure  of  a small  proofchcckcr  which  uses  and  proves  state  deltas.  Chapter  four  is 
devoted  to  a description  of  the  IMP  and  and  a dcscnption  and  informal  proof  of 
tmicuness  of  the  btillcr  allocation  lutitme,  named  til  Rf.V.  A Complete  loimal  p'loof  of 
correctness  of  this  same  code  lias  been  verified  by  the  verification  system  and  it  is 
displayed  and  annotated  in  chapter  five.  Chapter  six  contains  reflections  on  the  current 
wcuk  and  directions  for  the  future. 

All  of  the  programs  developed  during  the  course  of  this  research  were  written  in 
Interlisp.  This  choice  was  intentional,  for  it  was  clear  at  the  outset  that  only  the 
availability  of  such  a powerful  system  would  enable  one  person  to  experiment  with  a 


6 


theory  by  implementing  and  re  implementing  various  ideas.  Interlisp  not  only  supported 
all  of  the  programming  I needed  to  do,  but  it  also  supported  the  definition  of  language 
for  state  descriptions  and  state  deltas  and  provided  a powerful  pattern  matching  facility 
for  use  in  a command  language  for  the  verification  system.  1 hese  uses  of  Interlisp  fall 
somewhat  outside  the  design  intentions  of  the  Interlisp  architects  and  the  fit  was  not 
quite  perfect;  some  of  tire  syntax  may  seem  a Utile  awl- ward  For  a production  vrrsicr 
of  the  verification  system,  it  is  almost  certain  that  all  of  the  interfaces  would  have  to  be 
redesigned. 
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2.  The  Formalism 


The  pattern  for  proving  faces  about  a program  is  to  represent  each  of  its  steps  as 
a state  delta  and  then  prove  facts  about  sequences  of  steps.  The  new  facts  will  also  be 
represented  as  Sl)s  and  thus  may  be  used  in  further  proofs. 

We  will  come  to  the  precise  formulation  of  SDs  shortly,  but  we  know  that  they 
contain  a modification  hst  and  two  partial  state  descriptions,  viz.  the  precondition  and 
the  postcondition.  Given  a set  of  known  SDs,  we  will  attempt  prove  a new  SD  in  the 
following  manner. 

1.  Write  down  the  precondition  for  the  SD  to  be  proven.  This  constitutes  the  initial 
"current  state". 

2.  Select  a known  SI)  whose  precondition  is  true  for  the  current  state  and  apply  It. 
After  the  Si)  is  applied,  there  will  be  a new  current  state 

3 If  the  new  current  state  meets  the  requirements  of  the  postcondition  in  the  SD 
being  proven,  the  proof  is  finished  If  not,  step  two  is  repeated  until  a state  is 
reached  that  is  satisfactory. 

"Application"  of  a SD  to  the  current  state  has  two  subparts.  First,  clauses  in  the 
current  state  that  depend  upon  the  contents  of  one  or  more  places  being  modified  must 
be  removed  from  the  current  state.  After  this  has  been  done,  the  postcondition  of  the 
SD  being  applied  is  added  to  the  state  and  the  total  result  is  the  new  current  state. 


21  Descriptions 


A computer  has  a set  of  places  (sometimes  called  locations)  which  hold  values. 
T he  collection  of  values  stored  in  the  places  at  a given  time  is  the  state  of  the  machine 
at  that  time 

Places  a'c  cither  simple,  structural  or  invented.  Simple  places  hold  non  negative 
integers  in  the  range  0 through  2n~K  where  n is  the  length  of  the  place.  Simple  places 
are  used  to  model  single  registers  or  flip-flops. 
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Structured  places  hold  lists.  Structured  places  are  used  to  model  the  memory 
array  and  other  places  which  hold  more  than  one  element.  As  we  will  see  later, 
structured  places  will  also  be  used  to  model  subsections  of  memory,  including  non- 
contiguous subsections 

Invented  places  are  used  to  map  control  into  the  state  description.  Our  only  use 
of  invented  places  in  the  present  work  is  to  model  a fictitious  microprogram  counter  and 
a set  of  places  to  hold  "return  addresses"  for  the  microprogram.  The  values  stored  in 
invented  places  arc  just  labels  with  no  intrinsic  structure.  The  only  operations  available 
for  labels  arc  movement  from  one  place  to  another  and  comparison  for  equality. 

1 considered  formulating  simple  places  as  holding  bitstrings  and  defining  the 
various  operators  accordingly.  Selection  of  a field  from  a word  is  a typical  operation 
performed  on  values  in  simple  places  and  has  a very  simple  definition  in  terms  of 
bitstrings.  'I  he  major  drawback  of  using  bitstrings,  however,  is  that  there  has  to  be  an 
interface  to  the  integers  at  some  point,  and  it  becomes  tedious  if  car  led  out  at  the  bit 
level.  For  example,  after  selecting  a single  bit  from  a bitstring,  the  value  is  still  a 
bitstring  (of  length  1)  and  is  not  officially  comparable  to  an  integer  0 or  1.  Just  the 
matter  of  writing  down  constants  becomes  a chore  either  a constant  is  an  integer  and 
must  be  explicitly  'onverted  to  a bitstring  of  some  length,  or  it  is  initially  a bitstring  and 
the  length  must  be  s,  -cified  along  with  its  value 

Using  integers  as  the  values  for  simple  places  turned  out  to  be  easier  than  1 had 
fust  guessed.  Selection  of  fields  and  other  "bilstring  oriented"  operations  can  be 
characterised  in  terms  of  integer  division  (remainder  and  quotient)  and  the  interface 
between  selection  of  elements  from  an  array  and  selection  of  "bits"  from  an  integer  can 
be  formulated  relatively  cleanly. 

Our  concern  is  almost  always  with  a set  of  related  states  instead  of  just  a 
particular  state.  To  describe  just  the  set  of  states  of  interest,  we  use  a state  description. 
A state  description  is  just  a list  of  clauses  in  the  fust  order  predicate  calculus.  The  list 
is  understood  to  be  a conjunction  In  addition  to  the  logical  connectives,  quantifiers  and 
equality,  a number  of  operators  and  predicates  are  predefined.  The  user  may  also 
define  his  own  operators  and  predicates.  T he  predefined  operators  are  introduced 
below  For  each  of  these  operators,  there  is  an  infix  form  and  an  prefix  form.  The 
verification  system  accepts  either  form  for  input  and  converts  all  inputs  to  prefix  for 
processing.  When  clauses  are  output,  they  are  converted  to  infix  form. 
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2.1.1  Contents  of 


I use  a contrnts-of  operator  to  refer  to  the  value  stored  in  a place  in  a given  state. 
Its  external  syntax  is  a unary  prefix  period  and  its  internal  form  Is  DOT. 

The  use  of  a contcnts-of  operator  provides  for  a distinction  between  the  name  of 
a place  and  its  contents.  We  will  need  this  distinction  in  analyzing  indirect  addressing 
computations  and  structures  involving  pointers 

Using  the  contcnts-of  operator,  we  can  write  an  example  of  a simple  state 
description: 

. f’C=b  and  . A-0. 


This  state  description  refers  to  any  state  which  has  b stored  in  PC  and  0 in  A . 
The  values  in  all  the  other  places  are  unconstrained. 


2.1.2  Selection 


Many  of  the  places  will  be  considcied  to  hold  arrays  or  sequences.  In  order  to 
refer  to  a particular  element,  a selection  operator  is  provided  The  external  syntax  for 
the  selection  operator  is  ■>  and  its  internal  form  is  SLL  nLM=S  represents  the  sixth 
element  of  MtM.^  (All  arrays  and  sequences  are  indexed  from  zero.) 

fit  n-S  is  the  name  of  a place.  Us  contents  are  .riLM°b.  T his  notation  is 
potentially  ambiguous,  for  it  is  not  dear  whether  the  selection  operator  or  the  contcnts-of 
operator  has  higher  precedence.  If  the  contcnts-of  operator  has  higher  precedence,  then 
.Mm-S  means  ( . PIC M)  This  means  that  the  value  of  the  whole  array  is  first 

obtained  and  then  element  5 is  extracted.  This  interpretation  means  that  the  selection 
operator  would  be  operating  on  a value  instead  of  a place. 

In  contrast,  if  the  selection  operator  has  higher  precedence,  . Mtt1»5  will  be 
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‘ Tlir  rlioiio  of  nol,ilinii  is  heavily  nifluenml  liy  1 lie  availability  of  Cl. ISP  which 
li.uiclalrs  a u I orn.i  I ir  .1 1 1 y fiom  internal  lo  external  syntax  and  hark  apam.  The  convenience  of 
llits  facility  has  on  I wnplicd  the  nuisance  of  usmf  a non-standard  notation.  Kor  a production 
system,  I expcrl  lhal  a ilifferenl  external  syntax  would  he  developed. 
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interpreted  as  . (f1[l1°5),  meaning  the  contents  of  the  place  designated  as  the  sixth 
component  place  of  ITEM. 


Kithcr  of  the  these  interpretations  should  lead  to  the  same  value,  but  we  will  see 
that  it  is  desirable  to  minimize  the  size  of  the  places  that  appear  under  the  contents-of 
operator.  Accordingly,  I have  chosen  the  latter  interpretation  for  . fit M «5.  Of  course, 
the  former  interpretation  is  still  available  if  extra  parentheses  are  supplied. 


Selection  is  also  defined  for  integers;  the  result  is  equal  to  the  corresponding  bit  in 
the  binary  representation  of  the  integer,  i.e  , x<>0  =-  0 if  x is  even,  etc. 


2.1.3  indexof 


Given  a placcname  like  FREE,  it  is  often  desirable  to  find  its  address  in  memory. 
If  FREF^MEM° i for  some  i,  we'd  like  a way  to  refer  to  i.  The  indexof  operation  is 
provided  for  this  purpose..  Its  external  syntax  is  an  infix  /;  its  internal  syntax  is 
indexof.  If  f IIEF  = MEt1oi,  then  MREE/NEM.  The  second  name  must  be  a structured 
place  and  the  first  name  must  be  one  of  its  elements 


2.M  Segthru  and  Scgfrom 


These  operators  select  subsequences  of  structured  places,  structured  values  or 
integers  (ccgthru  X N)  extracts  elements  0 through  N of  X.  If  X is  an  integer, 
(segthru  X N)  takes  X modulo  2^^.  The  external  syntax  for  segthru  is 

(scgfrom  X N)  extracts  elements  from  N through  the  end  If  X is  an  integer, 
(scgfrom  X N),  is  the  integer  quotient  of  X divided  by  2 . The  external  syntax  of 
scgfrom  is 

i 

T ypical  use  of  these  operators  is  to  extract  a bit  field  from  a word.  .n; 13,10 
extracts  four  bits,  bits  10,  II,  12  and  13,  from  registers  IT  and  returns  an  integer  in  the 
range  0 through  15.  Reversing  the  operators  provides  a way  of  stating  the  first  clement 
and  the  uumbei  of  elements:  .IT;  13, 10=.N,  10:3.  Note  that  X,0  X.  When  working 
with  integers,  X»i  ■-  X;  i,  i.  However,  for  structured  places  and  values,  X;  i,  i has  the 
same  number  of  dimensions  as  X with  the  outer  dimension  equal  to  I,  while  X»  i has  one 
less  dimension  than  X.  Consequently,  X»i  * X;  i , i ->0  - X,  i »0 

\ 

f 

t 


II 


-p-u.. , ji lM,iLHjpp|B 


Following  die  policy  established  for  StL,  occifrom  and  sccjthru  have  lower 
precedence  than  liUT.  When  more  than  one  occurs,  they  arc  performed  left  to  right. 


2 2 Overlap  among  places 

Usually,  each  place  has  a single  name  and  is  isolated  from  all  other  places. 
Changing  the  value  stored  in  one  place  doesn’t  affect  the  value  stored  in  another  place. 

Arrays,  indirect  addresses  and  list  structures  all  require  a different  point  of  view. 
In  one  form  ot  another,  these  mcchansims  each  involve  dynamically  changing 
placenamcs.  As  a consequence,  we  may  not  know  whether  two  names  refer  to  the  same 
or  different  places. 

On r general  plan  for  following  programs  is  to  step  through  them  symbolically. 
Whenever  an  assignment  is  made  to  a place,  its  old  value  will  be  discarded.  Values  in 
other  places  remain  undisturbed  until  assignments  are  made  into  those  places. 

This  plan  dearly  requires  that  we  know  which  places  arc  disjoint  from  each  other 
whenever  an  assignment  is  made.  How  do  we  resolve  these  conflicting  requirements? 

First,  we  adopt  the  conservative  rule  that  unless  we  know  that  two  places  are 
disjoint,  we  must  assume  that  they  might  overlap  Second,  we  provide  a fast  and 
reasonably  flexible  mechanism  for  recording  and  accessing  the  overlap  relationships. 

Since  our  default  rule  is  that  places  overlap  unless  we  know  definitely  that  they 
do  not,  we  need  some  means  of  saying  that  two  places  do  not  overlap.  We  could  adopt  a 
predicate,  say  Uir.jointpfx  p),  which  asserts  that  x and  u aic  disjoint,  and  then  we 
could  make  up  axioms  for  deriving  disjointness  from  other  properties.  If  we  tried  to  do 
so,  we  would  encounter  a major  difficulty  in  working  with  a large  number  of  places.  To 
assert  that  three  places  are  each  disjoint  from  each  other  takes  three  statements,  four 
places  requires  six  statements,  five  takes  ten  statements,  etc  In  practice  we  need  to  assert 
that  perhaps  several  hundred  places  arc  each  disjoint  from  each  other;  several  thousand 
individual  oanricnccs  of  Uiojointp  would  required.  1 his  difficulty  could  be  remedied 
by  expanding  the  picdicatc  to  take  an  indefinite  number  of  arguments.  The  semantics 
would  be  that  each  of  the  arguments  is  pairwise  disjoint  from  each  of  the  others. 

In  addition  to  specifying  which  places  arc  disjoint  from  which  other  places,  there 
is  ficqpcnt  need  to  specify  that  one  or  more  places  arc  wholly  contained  within  another 
place.  Hoth  of  these  concepts  - disjointness  am.  subterritory  - arc  common,  and  1 have 
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chosen  to  combine  them  into  a single  predicate,  Lovering  (Lover  ing  <A  Bj  Bp  ... 
Bn>)  states  that  B]  through  Bn  are  disjoint  from  each  other  and  that  they  are  all 
contained  within  A. 

It  is  not  sufficient  to  have  these  relationships  scattered  about  in  the  state 
description.  When  a modification  is  made  to  one  of  the  places,  it  is  essential  to  know 
what  other  places  may  overlap  with  the  modified  place.  To  speed  up  the  search  among 
these  relationships,  a separate  data  structure  is  maintained  which  duplicates  the 
information  contained  in  the  Cover  ing  predicates  and  provides  immediate  access  to  all 
of  the  interactions  among  them.  This  data  structure  is  called  the  place  graph  and  is 
explained  in  detail  in  the  next  chapter.  The  most  important  point  about  the  place 
graph  is  that  every  place  that  is  referenced  within  a proof  is  expected  to  be  listed  in  the 
place  graph.  Places  listed  in  the  place  graph  are  said  to  be  registered.  Because  the 
place  graph  expects  to  know  about  all  places,  it  assumes  that  the  Cover  ing  relationships 
it  knows  about  are  definitive  and  that  all  overlaps  which  are  not  explicitly  barred  might 
actually  exist. 

Although  the  default  assumption  is  that  two  places  overlap  if  it  is  not  known  that 
they  do  not,  the  place  graph  is  organized  so  that  its  connections  show  what  does  overlap 
(or  at  least  might  overlap).  As  a consequence,  the  actual  searches  of  the  place  graph 
touch  only  the  nodes  corresponding  to  possible  overlapping  places.  Since  most  places  do 
not  overlap  with  most  other  places,  the  searches  of  the  place  graph  tend  to  be 
independent  of  the  size  of  the  place  graph.  This  is  an  important  result  and  contributes 
significantly  to  the  design  goal  of  a symbolic  execution  system  whose  execution  time  for 
a single  step  is  independent  of  the  size  of  the  program.** 

The  place  graph  is  initially  set  to  hold  a single  node  corresponding  to  the  place 
OMEGA.  ONEGA  represents  all  of  the  space  in  the  machine  and  everything  is  considered  to 
be  a subplace  of  ONEGA.  Relationships  are  added  to  the  place  graph  by  attachment  to 
existing  nodes,  so  the  first  relationship  added  to  the  place  graph  must  be  (Covering 
ONEGA  ...I, 


H Tli  it  f of  111  ii  I a I ion  of  lion  lo  liainllc  ilir  piohlrin  of  overlapping  names  was  inlhirnrcii 
li)  Itod  limslall's  clr/Miil  p.ipor  "Sonic  Tri  limqnrs  foi  Piovmi'  (.01 1 rrl  ness  of  Programs  which 
Alicr  Data  Si  nr  lures,"  m Machine  intelligence  7,  I'.ilniliur/'li  l uivrrsily  Press,  E.ihnhui/jh, 
Srollaml,  1972,  pp.  2.7-50.  I am  iniloblci!  lo  James  II.  Morris  Jr.  for  pomlinp  out  this  paper 
ilium/'  a iliseiission  on  liie  siihjecl  of  hoiv  lo  represeni  lisi  siriielnrrs. 
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3 Computation 


State  desci  iptions  provide  a characterization  of  a machine  at  a single  point  in 
time  The  next  step  is  to  describe  the  computational  process  as  the  machine  proceeds 
ftoin  01  sc  to  another.  The  basic  requirement  is  fur  some  way  to  state  "if  the 
machine  is  in  a state  characterized  by  1\  it  will  eventually  reach  a state  characterized  by 
Q",  where  P and  O are  stale  descriptions  l or  brevity  we  can  write  "P  leads  to  Q". 

The  general  plan  is  represent  the  hardware  as  a set  of  statements  in  this  form  and 
then  combine  these  statements  together  to  cover  long  sequences  of  computation.  Thus,  if 
we  have  "P  leads  to  O"  and  "O  leads  to  R".  we  expect  to  be  able  to  write  "P  leads  to  R". 
However,  this  notation  by  itself  suffers  from  a problem  mentioned  in  the  introduction: 
everything  relevant  to  later  computations  needs  to  be  included  in  each  of  the  state 
descriptions  between  the  first  time  it  becomes  true  and  the  last  timr  it  is  used 

To  avoid  this  burden,  an  explicit  list  of  places  which  are  modified  is  included  in 
the  description  of  the  the  computation  'The  semantics  of  a computation  are  now  "if  the 
machine  is  in  a state  characterized  by  P,  it  will  eventually  get  to  a state  characterized  by 
and  it  mill  do  so  without  modifying  the  contents  of  any  place  except  ( possibly ) those 
listed  m M."  All  of  this  is  summarized  by  (SIMprc: P)  (mod:  M ) (env:)  (post:Q) 
(varo: I ) . 


The  vars  clause  binds  variables  th..t  appear  in  P,  O mid  Nl.  It  is  simply  a 
convenient  alternative  to  using  a universal  quantifier. 

VxfSifl  (pre:  P ( x ) ) (mod:  M(xl)  (env:)  (post:  O(x))  (vars:)) 
is  identical  to 

(SI)  (pie:  P(xl)  (mod:  M(xl)  (env:)  (poet:  CMx))  (vars:  x) ) . 

Matcmcnts  of  this  form  are  called  state  deltas  and  form  the  basis  for  reasoning 
about  the  computational  process  We  can  still  combine  two  state  deltas  to  form  a third 
by  extending  our  picvious  notion  a bit:  if  P leads  to  O modifying  only  places  in  M and 
O loads  to  R,  modifying  only  places  in  N,  then  P Iraris  to  R modifying  only  places  in 
MuN 


The  env  clause  is  a list  of  places;  it  is  used  to  abbreviate  the  precondition.  In 
outer  to  characterize  the  operation  of  a subroutine,  the  precondition  would  need  to 
include  a listing  o!  the  code  as  well  as  the  constraints  on  the  data  structure.  L isting  the 
code  in  the  precondition  is  unwieldy  and  inefficient.  It  the  code  is  never  modified,  we 


would  like  to  avoid  both  the  repetition  of  the  code  in  the  precondition  and  the  cost  of 
rechccking  that  it  hasn’t  changed. 

When  the  SI)  is  entered  into  the  proof  system,  it  is  connected  to  the  current 
machine  state  by  its  environment  clause  When  the  SI)  is  used,  the  values  in  the 
niviionment  places  must  not  have  been  changed  since  the  SD  was  entered  into  the 
system.  If  they  had  been  changed,  the  SD  is  no  longer  valid  and  must  be  discarded. 


2 d Definition  of  the  3IG 


I’.clow  is  an  abbreviated  description  of  the  Honeywell  316  in  terms  of  SDs.  Only 
six  of  the  instructions  usually  found  on  316s  arc  included  here.  This  example  will  be 
used  later  as  part  of  the  input  for  the  proof  of  GFREF..  The  SDs  in  the  definition  of 
tire  316  will  not  have  any  places  listed  in  their  environment  clauses,  since  their  validity 
does  not  depend  upon  some  part  of  the  machine  state  remaining  constant.  We  will  see 
examples  of  the  use  of  the  env  clause  later. 


The  machine  is  assumed  to  have  a memory  hfcfl,  a program  counter  PC,  an  A 
register  A,  and  internal  registers  M,  OP,  1 and  UPC  to  hold  an  address,  operation  code, 
indirect  addressing  flag  and  microprogram  locations,  respectively.  These  internal 
registers  are  all  considered  to  be  subcomponents  of  Q,  so  a change  to  Q changes  (perhaps) 
all  of  the  internal  registers. 


This  use  of  U is  merely  a convenience;  the  list  of  M,  OP,  I and  UPC  could  have 
been  written  explicitly  in  the  mod  clauses  of  the  SDs,  but  it  was  convenient  to 
summarize  the  set  with  a covering  place. 

The  following  list  of  SDs  is  the  actual  set  used  in  the  proof  of  GFREE  described 
later.  The  place  named  UPC  is  an  invented  place,  and  it  represents  a microprogram 
counter.  For  this  simple  example,  its  values  are  represented  as  top,  arldr  and  action/* 


(SO  (pro:  .UrC^top  .PGpc  .MtM°  ( .PC)  - 1400400) 
(mod:  0 PC  A) 

(env: ) 

(poet:  .UPC-  top  . PC- (pc i 1 ) ; 13  .ADI 
(vcirs:  pell 
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The  suffix  Q on  numliers  unlieaies  llic  unrulier  is  octal. 


This  convention  was  chosen 


to  conform  Willi  ihc  available  facilities  in  Inlcrhsp. 
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(SO  (prc:  . UPC-  top  .PC=pc  .fit  Mo  (. PC) -1010400) 

(mud:  0 F'C) 

(rnv: ) 

(post:  .UI’C  tup  (if  . A'0 

then  .PC'  (pc-tl) ; 13 
else  . PC- (pen 2) ; 1 3 ) ) 

(vnrs:  pc)) 

(SO  (prc:  .UPC- top  .tlLM®  (.PC) ; 13. 10^-0) 

(mud:  Q) 

(env: ) 

(post:  .OP-.rtn»(.PC);13,10  .UPC-addr  . I =.t1EU®  ( .PC)  “15 
(if  .HI  Ho(.PC)  -9-0 

then  .n-.nEri“(.PC);8 

else  . M=  .Mfc.fi® (. PC) ; 8-t  (10GAND  .PC.  377000Q) ) ) 

Ivors: ) ) 

(SU  (pie:  .HI  C-  jcldr  .1-0) 

(iihhI:  UPC) 

(env:  ) 

(post:  .UPC- act  ion) 

(vnrs: ) ) 

(SL)  (pee:  . UPC- addr  .1  = 1 .M  m) 

(mod:  UPC  ! M) 

(env:  ) 

(post:  . UPC- addr  .M-- . fit M“ni;  13  . 1 = . MtM«»ni®15) 

(vors:  m) ) 

(SO  (pi  e:  .UPC- act  ion  .OP-1  .N-nd 
(mud:  0 PC) 

( env : ) 

(post:  .UPC- top  .PC' nil 

(vors:  in)) 

(SO  (pie:  .UPC  action  .0P--A  . M- m .PC' pc) 

(mud:  (I  PC  Ml  U n m ) 

( rnv: ) 

(post:  .UPC- top  .PC-  (pc-il ) ; 13  .MLII-nu  .A) 

(vors:  m pc)) 
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(SL) 


(prc:  .UPC- act  ion  .OP-=10  .H=m  .flEflan^v  ,PC=pc) 

(mod:  Q PC  ME  Mom) 

(onv: ) 

(post:  .UPC- top  .t1Lt1om=  (v4l) ; IB  (if  . MEM  ^ ai= 0 

then  ( . PC-pc+2) ; 13 
else  . PC- (pc+1) ; 13) ) 


(vars:  m pc  v)) 


(SO  (prc:  .UPC-action  .OP^ll  .PC-pc  .A- a .f1=m  . f1Ef1°rii=b) 
(mod:  Q PC  A flEfl-m) 

(onv: ) 

(post:  . UPC-  top  . PC=  (pc-t  1 ) ; 13  JWb  .MEII-ni-a) 

(vars:  pc  m a b)) 


2.5  Computation  of  support 


i 
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P>y  support  1 mean  the  set  of  places  whose  contents  are  referenced  in  the 
expression.  The  truth  value  of  a predicate  depends  upon  the  contents  of  the  places 
referenced  remaining  the  saim.  If  any  of  the  contents  are  changed,  then  the  truth  of  the 
predicate  is  suspect.  Our  strategy  will  be  to  delete  predicates  from  the  list  of  known-to- 
be-valid  predicates  whenever  my  place  in  its  set  of  support  is  changed  This  strategy  is 
conservative  and  can  never  .cad  to  an  inconsistency.  However,  it  is  quite  possible  for 
information  to  be  lost,  lor  example,  the  predicate  . X-.X=0  is  always  true,  ro  matter 
how  the  contents  of  X are  modified.  The  algorithms  1 am  using  to  compute  support 
treat  this  predicate  as  if  it  is  supported  by  X.  As  a consequence,  some  care  by  the  user 
may  be  necessary  in  constructing  his  predicates. 

The  basic  rule  for  computing  support  is  just  to  collect  the  set  of  places  that  occur 
within  a predicate  under  the  scope  of  the  contents  of  operator  (U01).  There  are  several 
exceptions,  however.  The  following  is  the  precise  formulation  used  in  the  system. 

Two  functions  are  used  to  compute  the  support  of  an  expression,  Support  and 
Structure.  Structure  analyzes  expressions  containing  names  of  places  which  are  used 
within  the  scope  of  a OUT.  Support  takes  the  union  of  the  support  of  the 
subexpressions  until  it  reaches  a UOT  or  another  special  form.  When  reaching  a DOT, 
Support  uses  the  structure  o;  the  referenced  place  or  place-expression. 

The  special  cases  are  the  following. 


r.S&Ji 
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State  deltas  have  an  explicit  representation  of  their  support,  declared  when 
they  are  proven  In  the  state  delta  this  is  the  environment  clause. 

Quantified  expressions  behave  as  if  the  structure  of  each  of  the  bound 
variables  is  0NLGA. 

T he  support  of  expressions  headed  by  a use;  defined  name  is  dependent 
upon  the  definition  of  the  name  When  the  name  is  defined,  the  user  is 
responsible  for  declaring  the  rule  to  be  used  in  computing  the  support  of 
expressions  headed  by  the  name.  The  default  rule  is  to  take  the  union  of 
the  support  of  each  of  the  arguments  to  the  expression;  if  the  default  rule  is 
correct  for  a particular  name,  then  no  specific  rule  need  be  stored  and 
Support  will  assume  the  default  rule.  If  a special  rule  is  necessary,  it  must 
be  in  the  form  of  the  union  of  some  subset  of  (usually  all)  of  the  arguments 
and  a list  of  constants 

In  all  eases,  when  a new  name  is  introduced,  the  user  must  prove  that  the 
rule  foi  computing  support  of  expressions  headed  by  that  name  is  correct. 
"Correct"  means  that  the  rule  computes  a list  of  placenames  which  entirely 
covets  the  places  holding  values  used  in  the  definition  of  the  predicate.  For 
predicates  which  arc  not  defined  recursively,  this  simply  means  that  the  list 
of  places  computed  by  the  rule  must  cover  the  list  of  places  computed  by 
applying  Support  to  the  definition  of  the  predicate. 

l ot  predicates  defined  recursively,  the  same  criterion  is  used,  except  that  the 
proposed  rule  for  computing  support  is  used  in  the  appearances  of  the  new 
predicate  m the  definition. 

The  following  example  illustrates  computation  of  support  for  a new  predicate. 
(F'acketUuf  fori  iotp  x ij)  is  defined  to  be 

(Subuet  x I'.uf ferepoce)  and 
t|/0  and 

Uj  ir.  let.:;  than  H//770)  and 
(if  (II  MG  111  x)-0 
then  i|  /II (0/1  ll  11 
clue  O'acketUuf ferp  x)  and 
u xo|'M)/iU  (I  and 

(I’aekc tlluf  f erL  i stp  x,l  . xnBnDI) 

'I  lie  i tile  for  computing  the  support  for  this  predicate  is 
(UNION  (Support  .x)  (Support  lj ) ) 


IS 


Tim  rule  is  correct  if  it  can  be  shown  to  cover  the  support  of  the  definition.  The 
support  of  the  definition  is 

(UNION  (Support  (Subset  x Duf ferspace) ) 

(Support  y^B) 

(Support  (y  is  less  than  37/77Q)) 

(Support  (If NOTH  x) -0) 

(Support  y ZhFiO/MEM) 

(Support  (PacketBuf ferp  x)) 

(Support  y-x°0°0/f1Ef1) 

(Suuport  (PacketBuf fcrL i stp  x,l  . x°0°0))) 

The  first  seven  clauses  simplify  to 

(UNION  (Support  x)  (Support  y) ) 


The  last  clause  makes  use  of  the  rule  being  tested  and  produces 
(UNION  (Support  .x,l)  (Support  .x°0°0)) 


Altogether,  it  thus  required  to  show  that 

(UNION  (Support  x) 

(Support  y) 

(Support  .x,l) 

(Support  .x«0o0)) 


is  a subset  of 


(UNION  (Support  .x)  (Support  y)) 


The  rule  for  computing  the  support  of  a "dotted"  form  is  just  to  take  the  union  of 
the  structure  of  form  under  the  dot  with  the  support  of  the  form  under  the  dot.  (This 
latter  part  is  lequucd  because  the  form  may  have  other  dots  nested  deeper.)  For  the 
cases  at  hand,  we  have 

(Support  .x)  t-  (Structure  x)  U (Support  x) 

(Support  .x.l)  ■ (Structure  x,l)  U (Support  x) 

(Support  .xo0D0)  t (Structure  xo0«0)  U (Support  x) 
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are  both  subsets  of 


Since  (Structure  x,l)  and  (Structure  x°0°0) 
(Structure  x),  the  proof  is  complete. 


?.G  Machine  descriptions  revisited 

As  described  above,  the  plan  is  represent  the  basic  machine  in  terms  of  a set  of 
Sl)s  and  to  use  these  SDs  to  prove  facts  about  the  operation  of  the  IMP  code  The 
original  set  of  SDs  tc  represent  the  machine  must  be  invented  by  the  user  and  input  to 
the  system 

While  it  is  feasible  for  the  user  to  write  his  own  machine  descriptions  using  SDs, 
Kell  and  Newell  have  already  pioneered  the  machine  description  area  and  invented  a 
quite  reasonable  notation,  ISP.  More  recent  work  by  Karbacci,  Karnes,  Cattell  and 
Sicwiorek  Iras  evolved  the  language  and  provided  tools  for  manipulating  descriptions 
written  in  ISPS,  the  current  derivative  of  ISP.'^ 

I experimented  with  ISPS  and  wrote  the  following  description  of  the  Honeywell 
316  in  ISPS  Only  a skeleton  of  the  input-output  structure  is  given,  but  the  rest  of  the 
description  is  intended  to  be  complete.' 1 


Tim  oripuial  ISI’  notation  is  documented  in  Computer  Structures : Rcadinps  and 
[ ram  pics,  liy  Cordon  Kell  and  Allen  Newell,  published  by  McGraw-Hill  hook  Company,  New 
York,  1071.  The  most  rcrrni  ilcscripiion  of  ISI’S  is  an  internal  Cai  rirpic-Mellon  University 
u pon,  "Tlir  ISPS  Computer  Description  l.anpuapc,"  liy  Mario  Barliacci,  Cary  harries,  Kirk 
Gat  loll  arid  Darnel  Sicwiorek,  doled  Aupust  M,  1077  and  available  from  I lie  Computer  Science 
Department  at  Caine/’ie-Mellon  University. 

' ' Tlir  luilk  of  this  description  comes  from  1 lie  F'roprammcrs  Reference  Manual:  DDP- 
516  General  Purpose  Computer,  published  by  Honeywell  I nr.,  kramiripliam,  Massachusetts, 
lOfdl  However,  a number  of  details  were  not  clear  in  ihe  manual  and  I asked  for  assistance 
from  the  IMP  crew  al  hh\.  Most  of  the  questions  I asked  were  answerable  immediately  from 
prarlir.il  experience  with  the  hardware.  A few  questions,  however,  required  experimentation 
Willi  ibe  machine  io  si  e how  it  would  behave.  These  questions  arose  just  from  the  atiempt  to 
prepare  a forni.il  description  of  the  machine.  The  fuel  that  llns  exercise  forced  these  details  to 
be  made  explicit  sir, -/'■sis  lhal  formal  description  of  computers  may  be  beneficial  to 
aieliileel ure  designers  aid  inimical  manual  wrtlers  independent  of  any  niilornaiic  processes 
lhal  may  be  applied  io  I,  e descriptions.  I aril  indebted  lo  entire  IMP  rrew  at  hhN  for  ibeir 
assistance  in  prcp.ituip  llns  description  ami  their  patience  and  responsiveness  is  ferrelinp  out 
the  details  r.f  bow  ihe  machine  behaves  under  various  unlikely  sequences  of  instructions. 
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H316  :=  ( 
fnV  hp. State  VnV 
mem  [0: #77777] <1S:0>, 

x<15:0>  :=  mem [03 <15: 0>  ! I ndex  register  is  cell  0 
ft*  Pc. State 


c<>,  (carry  bi t 

a<15:0>,  ! accumu I ator  --  referred  to  below  as  A 

y<14:0>,  ! internal  register  --  holds  effective  address 

ea<14:0>  :=  y<14:0>,  (another  name  for  same 
m<15:0>,  (internal  register  — holds  word  fetched  from  mem 

op<3:0>,  (internal  register  --  hangs  onto  op  field 

cxx<>,  (internal  register  --  hangs  onto  index  bit 

b<lS:0>,  (extension  of  accumulator 

pc<14:0>,  (program  counter 

sc<5:0>,  (shift  counter  — used  only  for  shifts,  OTK  and  INK 

xao,  (extend  mode  option: 

(1  = > extended  addressing  hardware  exists, 

(0  =>  not 

scxtfo,  (0  «>  disable  extended  addressing  at  next  JtlP 

extmdo,  (1  *>  in  extended  addressing  mode,  0 *>  not 


it  it  t f fee  t i vc.  Address. Ca  I cu  I at  i on  ** 


humppeO  : (IWrnde  extmd  (pc<13:0><  pc-il , pr*pc+l)), 

dxeaO  (If  m<)4>  =>  (ea<- (ea+x) <13: 0>)  next 

If  m<15>  ->  (m«  mem  tea)  next  y«-m  next  Loop  dxea)  ) , 

exeaO  :=  (Recode  m<l&>  =>  (0  (if  m<14>  =>  ea<~ea+x)  , 

1 : - (m<  meni  leal  next  y*-m  next  Loop  exea)  ) ) , 

effacJdrO  ( Decode  extmd  =>  (dxeaO,  exeaO)), 

xeffaddrO  ( Decode  extmd  =>  ( 

0 :=  (If  m<lb>  =>  m<-nieo (ea)  next  dxeaO), 

1 :■  (If  m < 1 5>  ->  m<memrea)  next  Loop  xeffaddr))) 

itit  I notruc  t i on.E  xecu t i on  itit 

interrupts!)  :=  ( 

i it  1 n t erna  I . Reg  i s ter s itit 

i <lb: 0>, 
i msb<14 : 0>, 
xmslxlb:  0> 

itit  Internal. Procedure  itit 

priority!)  (If  i and  xmsb  eg  I 0 =>  ( 
imsb«- imsb-il  next 
xmsb*  xmslxlb:  1 > next 
loop  priority)) 

itit  fin  i n . Hou  t i ne  itit 

Start.MainO  :=  ( 

i<  in  ten  and  in  try  next 
If  pi  and  ( i neq  0)  ( 

( ini<..b« //(/»;  xmr>b*-//l 00000  next  priority!)); 

(r.pi«0;  pi«0;  pmi*-extmd;  sextOxa  next  extmd*-xa)  next 
i n*  mem  [ i msb)  next 
intrq«  intrq  xor  xmsb  next 
j e t ( ) ) ) ) , 


fetchO  s - ( 

nxmemlpc)  next  (Fetch  instruction 

exx*m<14>;  o|d<  m<13: 10>;  y<8:0>*-m  next  (Save  index  bit  and  opcode 
!f  xtend  address  uitli  either  0 or  high-order  bits  of  pc, 

(according  to  page  bit 

Decode  m<9>  =>  ( y < 1 A : 9>«-0,  y<14:9>* pc<14:9>)  next 
bumppe  () ) , 

generics0()  : --  (Decode  m<9:0>  = > ( 

//1I\EXA  :=  (sextf*-xa;  extmd*-xa) , (Enter  extended  addressing  mode 

//1 3 \DXA  scxtf«0,  Heave  extended  addressing  mode 

//43\INK  (a<lb>«c;  ! Input  keys 

a<14>«-undef  ined  ( ) ; 
a<13><  pm i ; 
a<12:5>*0; 
a<4 : 0>*-sc) , 

//201XIAB  : = (a<?b»bea;  sc«-undef  i ned  0 ) , (Interchange  A and  B 
//401XENB  :=  spi«-l,  (Enable  interrupts 

//1001MNII  :=  (pi<0;  spi«-0))),  (Inhibit  interrupts 

shift.  I oop  ( ) : «■  ( 

If  sc  LUl.  0 *>  (leave  shift,  loop)  next 
Decode  m<9:6>  = > ( 


0\LF(L 

= 

ai?bec«-aeb. 

(Long  r i ght  1 ogi ca 1 

1 \LRS 

=■ 

a<lA : 0>eb<14 : 0>@c^a@b<14 : 0>, 

(Long  right  arithmetic 

?\l.RR 

arh©c«-b<0>eaeb, 

(Long  right  circular 

3\S403 

= 

undcf i ned. act i on  0 , 

(Non-ex i stent 

AM  GR 

er 

auc«-a. 

(Logical  right 

&\ARS 

e 

a<lA:0>ec*-a, 

! Ar i thmet i c r i ght 

6\ARR 

= 

aye*  a<0>ea. 

(Circular  right 

7\SA07 

undef i ned. act i on  0 , 

(Non-exi stent 

8\Ll  L 

cenob* oobez. 

(Long  left  logical 

9\LLS 

= 

(c«-c  or  (a<15>  xor  a < 1 A > ) next 

atrbclA : 0>*  a<l A:  0>eb<l A:  0>ez) , 

(Long  left  arithmetic 

18ULR 

! 

ceai?b«-a<?bea<lE», 

(Long  left  circular 

1 1 \SA 1 3 

r: 

unde  f i ned .action!), 

(Non-exi stent 

1?\LGL 

= 

ti?a«  3GZ, 

(Logical  left 

13NALS 

r 

(c<  c or  (a<15>  xor  a<lA>)  next 

a<  a<lA: 0>ez) , 

(Ar i thmet i c 1 er  t 

1ANALR 

c«?a«  ap3<lb>, 

(Circular  left 

1BNSA17 

i 

undcf i ned. act i on 0 ) next 

(Non-exi stent 

sc^sc+1  next  loop  shift. loop). 


$$  KVNUBlt 


sk i p ( ) : = 
(ni<G> 
( m < A > 
(m<2> 
(m<0> 


(If  m<Sl>  c:c|v  ((m<8>  and  a<15>)  or 
and  a<()>)  or  (m<b>  and  (a  NL  □ 0))  or 
anil  ssl ) or'  (m<3>  and  cs2l  or 
and  cs3)  or  ( m< 1 > and  ssA)  or 
and  c ) ) =>  (bumppc  ( ) ) ) , (SSC/SRC 


ISLN/SLZ  & SNZ/SZE 
! SSI /SHI  & SS2/SR2 
(SS3/SR3  & SSA/CR4 


goner  ic  si  400  0 
//0040\CRA  : 
//121GXACA  : 
III  20G\ADA  : 
//140ATCA  : 
//0320XCSA  : 
//0024  \CHS  : 
//H401\CMA  : 
//0G00\SSM  : 
//0100XSSP  : 
//0?00\RCR  : 
//0H00\SCB  : 
//:.  0b0\CAL  : 
//]  844\CAR  : 
//1 3 A 0\ IGA  : 
//l  143MCL  : 
//l  24  0\  ICR  : 


» (Decode  m<9:0>  =>  ( 
a*0. 

cira<  a+c, 
ro-a<  a+1 , 
a<  - a, 

(c<  a<lb>  next  a<lb><0), 

a<lb><  Not  a<lb>, 

at  Not  a, 

a<lG>t 1 , 

a<lb>< 0, 

c<  0, 

c<  1 , 

a<lb: 8><  0, 
a <7 : 0>»  0, 
a<  a<7: 0>e>a<lb:8>, 
a< a<lb:8>, 

a<7: 0>oa<lb:  8>«-a<7:  0> ) ) , 


'Clear  A 

!Add  carry  to  A 

!Add  one  to  A 

lino' s complement  of  A 

'.Copy  sign 

(Change  sign 

! Comp  lenient  A 

!Sct  sign  minus 

! be  t sign  plus 

(Reset  carry  bi  t 

•So t carry  b i t 

(Clear  left  part  of  A 

(Clear  right  part  of  A 

(Interchange  characters  in  A 

(Interchange  and  clear  left 

(Interchange  and  clear  right 


generiesO  : - (Decode  m<lb:14>  =>  ( 

0 :=  gencricsHO, 

1 : ( c.c> nr.  c*  0 next  eh i f t . I oop  ( ) ) , (shifts 

2 : = sk i p ( ) , (skips 

3 goner  ics]  400  0 )) , 


jmp()  :*  ((decode  extmd  «>  (pc<13: 0>»-ea,  pc*-ea))  next 
cxtnul'oextf  and  xa) , (Jump 


I da ( ) :*  (a* mem  leal). 


ana (I  : ■ (a< mom (cal  and  a). 


stall  : «-  (mem  leal  * a) , 


cia()  : ■ (a<  nirm  [cal  xor  a), 


add()  o (c  ^a<  at  mem  leal ) , 


!l  oad  A 


(And  to  A 


(Store  A 


!(  xc I us i vr  or  to  A 


(Add 


?•! 


— 


sub()  :=  (c:pa<  a-mem  lea) ) , (Subtract 


j s t ( ) : = ( 

decode  extmd  ->  (0 
1 


(Jump  and  store 

(ment  [e3]  <13: 0>«  pc  next  pc<13: 0>«~ea+l ) , 
(mem  [ea]  <14: 0>*-pc  next  pc*-ea+l ) ) ) , 


cast)  :-  ( 

m< mem  leal  next 

Decode  a tst  m =>  (0\lSS 

1 \EQL 
?\GTR 


(Compare  A and  storage 

(bumppcO  next  bumppe  ( ) ) , 
buntppe  0 , 
pct-pc) ) , 


irsO  ( (Increment  and  skip  on  zero 

m<  mem  (cal -*  1 next 
mcm(eal*-m  next 
If  m EQL.  0 - > bumppcO}, 

iniaO  : * ( (Interchange  memory  and  A 

m<mem(ea]  next 
mcm[eal«-a  next 
a<  m) , 


ocp()  (Decode  m<9:0>  *>  ( (Output  control  pulse 

4 : = ocp4  0 , 

//0101  Jr  C'-C, 

//0104  :*  c<  c, 

//0041  MASK  : = intrq<0>-l ) ) , 

sks()  :*  (Decode  m<9:0>  *>  ( (Skip  if  ready  line  set 

4 : *■  bumppe ( ) , 

//0I04  :*  bumppcO, 

tfl777\dummy  unde  fined,  act  ion())) , 

inaO  : ■*  (If  m<9>  «->  (a<  0)  next  (Input  to  A 
Decode  m<8:0>  «>  ( 

4 (ina4()  next  bumppcO), 

//777\dummy  undef  ined.act  ionO  ) ) , 


?b 


m 


jia()  (Decode  m<3:0>  ->  ( (Output  from  A 
A (otaAO  next  bunippcO), 

//0)?0\5DK  : intcn.-a, 

III  0?0\O (K  : ( 


c:*-n<]  sextf* 

o < 1 3 > ; sc*3<4 

:0>  next 

extmd«  cxtmcl  or 

SCXt  f ) ) ) , 

i.o()  : - (Decode  m<] 

S : 1 A > =>  ( 

0\OCP  orp 0 , 

1 \SKS  : = r-ksO, 

?\INA  innO, 

3\0TA  otaO 

(SDK  and  OIK  are  special 

Idx.stxO  :■  (Decode  exx  =>  ( 

mem  teal  «-x. 

(Load  index  register 

x<-  mem  leal  ) ) 

(Store  index  register 

itft  Instruct  ion.  Interpretat  ion  ** 

St ar  t . Da i n ( ) : ■ ( 

interrupted  next 

pi*  r.p i next 
fetchO  next 

Decode  op  *■>  (0 

* gencricsO, 

1 

- (effaddrO 

Next  jmpO  ) , 

? 

- (effaddrO 

Next  IdaO), 

3 

=■  (effaddrO 

Next  ana 0 ) . 

A 

- (effaddrO 

Next  staO), 

S 

f (effaddrO 

Next  era 0 ) . 

r; 

- (effaddrO 

Next  add 0 ) , 

7 

= (e f f atidr  ! ! 

Next  sub ( ) ) , 

//)0 

? (effaddrO 

Next  jst  0 ) , 

II 1 1 

(effarlcfrO 

Next  cast)). 

III? 

= (effaddrO 

Next  irs 0 ) , 

Ill  3 

(e  f f addr ( ) 

Next  imaO), 

II 14 

= i . o ( ) . 

U IS 

= (xcf  f addr ( 

Next  Idx. s tx  0 ) , 

//If. 

undcf  i ned.  ac  t ion  0 , (reserved 

Ill  7 

:=  unde f i ned. ac t i on 0 ) next  (reserved 

l oop  Star  t . Na  i n) ) 
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One  of  the  tools  provided  by  the  CMU  group  is  a parser  which  accepts  an  ISPS 
description  and  outputs  a parse  tree,  fully  parenthesised  In  prefix  format  and  available 
in  an  ASCII  file.  Using  the  facilities  of  the  ARPANET,  we  have  found  it  very 
convenient  to  generate  ISPS  descriptions  at  1SI  in  Los  Angeles,  ship  them  over  the 
ARPANET  to  Carncgie-Mellon  University  in  Pittsburgh,  parse  the  description  at 
CMU,  and  bring  the  parse  output  back  to  1SI.  The  whole  process  takes  10  to  15 
minutes. 

Charlie  Hayden  has  written  a program  which  accepts  the  parse  tree  as  input  and 
generates  state  deltas.'^  The  current  translation  of  the  full  description  of  the  516  results 
in  310  state  deltas  This  is  a large  number  of  state  deltas,  and  they  were  put  aside  for 
possible  later  use  The  primary  reason  for  the  large  number  is  that  a separate  state 
delta  is  generated  for  each  invocation  of  a function  within  an  expression.  Moreover, 
distinct  values  are  invented  for  the  fictitious  microprogram  counter,  resulting  in  a very 
large  number  of  unreadable,  generated  symbols. 

To  a certain  extent,  this  expansion  of  text  as  ISPS  descriptions  are  translated  into 
$t)s  is  unavoidable  because  Sl)s  provide  no  implicit  control  structures  and  all  "control" 
has  to  be  encoded  as  a set  of  changes  to  the  state  description.  Perhaps  the  most 
troublesome  aspect  of  this  large  number  of  SL)s  is  that  it  is  difficult  to  design  an 
efficient,  automatic  strategy  for  selecting  which  SL)  to  use  for  advancing  to  the  next 
state.  With  respect  to  this  particular  issue,  an  dea  has  recently  emerged  for  an  alternate 
representation  of  the  internal  state  of  the  machine  in  terms  of  what  state  deltas  are 
applicable  instead  of  giving  an  explicit  label  to  each  internal  state.  This  idea  is  detailed 
in  chapter  six. 


Durni/'  my  first  experiments  with  ISPS,  I wrote  a translator  from  ISPS  parse  trees 
mlo  exeeutahle  Inierlisp  eode,  Willi  llie  help  of  llir  C.Mli  fironp  on  ISPS  ih  tails  anil  some 
handhold  in/’  from  Marly  Yorike  mi  Inierlisp  details,  I was  able  lo  pul  together  a rudimentary 
It.mslalor  in  alioni  direr  weeks.  Charlie's  prop i am  is  initeh  cleaner  ami  oulpuls  holh 
exeeuiahle  code  in  bliss  and  stale  deltas.  The  01  panr/.al ion  of  the  pioprarn  permits  easy 
addition  of  oilier  modifies  lo  output  code  in  oilier  Itri/'uapcs.  Keeeiilly,  Hill  Overman  has 
exercised  this  possibility  by  wrilin/'  a trial  version  of  a Pl./l  code  pencralor.  The  cost  of  each 
of  these  efforts  has  been  quite  modest  ami  probably  would  not  have  been  undertaken  rf  the 
parser  were  not  available. 
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2.7  Formal  basis 


One  of  the  classical  formal  views  of  computing  looks  at  a computer  as  a transition 
function  E:S->S,  where  S is  the  set  of  possible  state  vectors  and  E is  the  rule  for 
advancing  the  computation  one  step.  Components  of  a state  vector  are  accessed  by 
using  the  name  of  the  component  as  an  index,  eg.,  g»A  refers  to  the  A component  of  the 
state  vector  and  G°(NEf1°E>)  refers  to  word  b of  the  fltfl  component  of  the  state  vector. 
(In  prefix  form,  these  are  (SEL  s A)  and  (SEL  g (SEL  HEN  5 ) ) , respectively.  By 
treating  SEL  as  an  associative  operator,  the  latter  expression  is  equivalent  to  (SEL  (SEL 
s (im)  S) , which  corresponds  to  (s°t"!EM)  °5). 


2.7.1  State  dt.  is 


One  way  to  look  at  state  deltas  is  as  a shorthand  for  a specialized  class  of 
formulas  involving  state  vectors  and  transition  functions  The  first  specialization  is  the 
suppression  of  any  explicit  representation  of  state  vectors.  The  operator  takes  a 
name  and  treats  it  as  an  index  into  the  current  state  vector.  Within  the  proof  system, 
only  one  state  vector  is  "current",  and  every  occurrence  of  a outside  of  a SD  is 
understood  to  represent  access  into  this  state  vector. 

The  second  specialization  is  the  suppression  of  any  explicit  representation  of  the 
transition  function.  In  place  of  statements  about  E,  state  deltas  represent  statements 
about  the  closure  of  E The  closure  of  E is  defined  by 

F Mo)  = (F  1 (g)  : i>8l, 

that  is, 

F * ( g ) - Ig,  F (g)  , F?(s),  F 3 ( r. ) . f'Mc),  ...  I. 

If  P'  and  G'  ate  the  pre-  and  postcondition  of  a SD  with  the  "."’s  replaced  by  indexed 
accesses  of  s.  the  SD  states  that 

(Ve)  (gcS  a P'  (g)  -•  (Hr/ ) (g'cF '•(-.)  aQ'Ig'P. 

In  common  sense  terms,  this  means  that  state  deltas  say  that  the  postcondition  will  be 
true  sometime  in  the  future,  but  nothing  is  said  about  exactly  how  many  steps  are 
needed  to  reach  such  a state.  While  we  normally  ?.  sume  that  the  SDs  that  we  use  as  an 
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axiomatic  description  of  the  hardware  are  somehow  fundamental  or  atomic,  nothing  in 
our  theory  or  proof  system  can  know  whether  a particular  SD  represents  an  atomic  step 
or  a long  sequence  of  steps.  This  limitation  simplifies  the  theory  by  providing  uniform 
treatment  of  all  computational  statements,  but  it  fails  to  provide  a basis  for  certain 
classes  of  arguments  in  which  it  is  important  to  know  all  of  the  possible  states  that  the 
machine  might  be  in. 

T he  third  specialization  concerns  the  machinery  to  relate  s'  to  s The 
modification  list,  II,  shows  which  components  of  s'  may  have  /alues  which  are  different 
from  the  same  components  of  s.  By  implication,  components  of  the  state  vector  which 
haven’t  changed  must  be  the  same.  The  statement  above  thus  requires  amendment  to 
show  that  s and.  s'  are  the  same  except  for  the  components  listed  in  the  modification 
list.  Because  component  names  are  permitted  to  overlap,  the  precise  relationship 
between  s and  s'  has  to  be  stated  in  terms  of  disjoint  indices.  If  we  use  ® to  stand  for 
disjoint,  the  statement  that  s'  is  the  same  as  s except  possibly  at  places  listed  in  II  is 
written 

VifVjfjcfl  -*  iej)  -*  s'®Us°i). 

Thus, 

(SLl  (pre:  P)  (mod:  fl)  (env:)  (post:  Q)  (vars: )) 
is  an  abbreviation  for 

VsIscS  aP'(s)  - Us' (s'cPv(s)  a Q'  (s' ) a 
Vi  (V  j ( jcM  -*  ieji  -»  s'®i=s»i))). 


2 7.2  The  proof  system 

T he  pioof  system  detailed  in  the  next  chapter  provides  the  machinery  for 
deriving  new  state  deltas  as  theorems  using  a given  set  of  state  deltas  as  axioms.  From 
the  point  of  view  of  a state  deica  as  an  abbreviation  of  a formula  involving  state  vectors 
and  transition  functions,  the  basic  design  of  the  proof  system  is  simply  the  following. 

When  a proof  is  begun,  the  SD  to  be  proven  is  given.  The  precondition  of  the 
SI),  P'  (a),  is  assumed  to  be  true,  and  the  goal  is  to  prove 


s' ”i- S“i ) ). 


t'/  (O'  (s' ) /.  Vi  (Vj  ( jcM  - i®j)  - 


The  pi  oof  steps  that  are  used  in  the  course  of  the  proof  fall  into  two  basic 
categories.  One  category  is  normal  derivation  in  which  formulas  are  combined  using 
the  normal  inference  rules  to  derive  additional  formulas.  The  second  kind  of  step  is 
one  which  advances  the  computation,  in  terms  of  state  vectors,  this  means  that  a SD  is 
used  to  derive  a fact  about  a future  state  vector  s'.  In  order  to  keep  the  bookkeeping 
quite  simple,  a rule  is  imposed  that  all  of  the  formulas  in  the  proof  must  refer  to  the 
same,  "current",  state  vector.  Thus,  when  a SL>  is  used  to  derive  a fact  about  a later 
state  vector,  all  of  the  formulas  in  the  proof  must  be  checked  for  consistency  with  the 
new  stare  vector.  This  checking  consists  of  nothing  more  than  an  examination  of  the 
support  of  the  formula  to  sec  if  substitution  of  s'  for  s would  be  valid.  If  so,  the 
formula  is  retained.  If  not,  the  formula  is  deleted  Deletion  of  facts  from  the  proof 
system  may  result  in  difficulty  in  proving  a true  theorem,  but  it  cannot  result  in 
inconsistency. 

The  formulas  that  are  valid  when  s'  is  substituted  for  s are  not  actually 
manipulated  because  they  do  not  actually  contain  occurrences  of  s.  Wherever  s would 
be  expected  to  occur,  " occurs  instead.  Thus,  serves  as  a kind  of  pronoun  for  the 
current  state  vector,  and  all  formulas  that  remain  valid  when  the  state  is  updated  from  s 
to  s'  arc  simply  left  intact.  The  interpretation  of  the  ","s  in  the  formulas  simply 
changes. 


l or  straightlmc  code,  all  that  is  required  is  that  a sufficient  number  of  SDs  be 
applied  to  dciivc  the  postcondition  in  the  SD  being  proven.  For  loops,  induction  is 
required.  Normally,  this  induction  will  be  carried  out  using  the  natural  numbers,  but 
any  well-founded  set  may  be  used  The  usual  form  of  a SD  that  covers  a loop  is 

(Vi >0)  (SCI  (pre:  P ( i ) ) (mod:  M)  (poet:  □) ) . 


The  postcondition  of  this  SD  specifies  what  the  situation  is  when  the  loop  is 
finished,  independent  of  the  number  of  times  the  loop  was  executed.  The  precondition, 
however,  specifies  the  situation  at  the  top  of  the  loop  m terms  of  the  number  of 
iterations  yet  to  go  The  method  for  deriving  this  SD  is  to  derive  two  simpler  SDs  and 
then  use  standard  mathematical  induction  rules  to  derive  the  form  above.  The  simpler 
SDs  arc 


(SI I (pre:  f’(fl))  (mo,..  I)  t : i ) ) and 

(VPOHSII  (pre:  P ( i -» 1 ) ) (mod:  ill  (poet:  P ( i ) ) ) . 
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The  first  SI)  describes  the  behavior  of  the  system  when  no  more  iterations  are  left 
and  serves  as  the  initial  step  in  the  induction.  The  second  SD  describes  the  behavior  of 
the  system  as  it  makes  one  step  through  the  loop  and  serves  as  the  increment  step  in  the 
induction. 


2.8  Comparison  with  oilier  formulations 


State  deltas  ate  related  to  a number  of  earlier  attempts  to  formalize  the  effects  of  a 
computational  process,  particularly  McCarthy's  "fluents",  Fikes  and  Nilsson’  operators  in 
STRIPS,  Hoare’s  axiom  system,  lgarashi,  London  and  Luckham’s  "frame  axiom",  and 
Manna  and  Waldinger’s  "intermittent  assertions". 


2.8.1  Fluents 


John  McCarthy  considered  the  problem  of  how  to  represent  chains  of  reasoning 
involving  cause  and  effect  relationships,  in  his  memo  entitled  "Situations,  Actions  and 
Causal  Laws",^  he  introduced  the  idea  of  a predicate  which  takes  a "situation”  as  an 
extra  argument.  The  situation  argument  plays  essentially  the  same  role  that  the  state 
vector  s plays  in  the  preceding  section.  McCarthy  also  introduced  an  abbreviation 
using  a similar  device  of  factoring  out  the  situation  argument.  Predicates  which 
implicitly  depended  upon  a situation  were  called  "fluents". 

In  McCarthy's  formulation,  fluents  were  connected  in  sentences  either  by  ordinary 
sentential  connectives  or  by  a special  operator,  "cause".  The  cause  operator  is  quite  close 
to  the  idea  of  a state  delta,  but  McCarthy  never  made  dear  how  to  keep  track  of  which 
fluents  referred  to  which  situations.  An  additional  difficulty  is  no  machinery  was 
provided  for  removing  facts  which  ceased  to  be  true 


n 

'•  Tlio  mrino  is  reprinted  in  Semantic  Information  Processing,  edited  by  Marvin 
Minsky,  MIT  Press,  Cambridge,  Massachusetts,  1968,  pp.  410-417.  A later  paper  with  P.  J. 
Hayes  Idled  "Some  Philosophical  Problems  from  the  Standpoint  of  Artificial  Intelligence,"  in 
Machine  Intelligence  4,  edited  by  IV  Mell/cr  and  I).  Mirliic,  American  F.lscvrer  Publishing  Co., 
I lie..  New  York,  l%9,  pp.  46.VS02. 


2 8.2  STRIPS 


In  the  context  of  building  a robot  which  can  solve  problems  such  as  moving 
objects  from  one  room  to  another,  Richard  Pikes  and  Nils  Nilsson  designed  the  STRIPS 
problem-solving  system11  In  the  STRIPS  system,  actions  are  represented  by  operators 
which  are  composed  of  a precondition,  an  add  list  and  a delete  list.  They  serve 
essentially  the  same  role  as  our  precondition,  postcondition  and  modification  list,  but  the 
delete  list  seems  to  be  structured  differently.  Elements  on  the  delete  list  usually  specify 
which  predicates  to  delete,  compared  with  our  formulation  of  specifying  which  places  no 
longer  hold  the  same  values  and  thus  searching  for  all  predicates  dependent  upon  the 
old  information. 

That  difference  aside,  the  STRIPS  operators  and  the  state  deltas  developed  here 
are  quite  similar.  The  biggest  difference  comes  in  the  application.  In  the  STRIPS 
system,  the  primary  focus  is  how  to  build  a system  which  will  invent  programs  composed 
of  the  STRIPS  operators.  In  contrast,  the  work  here  focuses  only  on  how  to  represent  a 
sequence  of  actions.  The  invention  process  is  assumed  to  be  a separate  problem. 


2 8.3  Hoare’s  axiom  system 


Turning  our  attention  to  formulations  specifically  oriented  toward  program 
verification,  we  sec  that  state  deltas  bear  some  resemblance  to  Hoare’s  systems  of 
axioms.11’  In  lloare’s  system,  actions  are  represented  as  PISIQ,  where  P is  the 
precondition,  Q is  the  postcondition,  and  S is  a segment  of  program  code.  Although  this 
notation  is  similar  to  ours  and  each  lends  itself  to  reasoning  about  sequential  code  by 
simply  matching  up  the  postcondition  of  one  predicate  with  the  precondition  of  the 
next,  there  are  several  differcnces. 

I With  state  deltas,  termination  is  included.  There  is  no  possibility  that 


11  Sec  "STRIPS:  A New  Approach  to  the  Application  of  Theorem  Proving  to  Problem 
Solvinp”,  in  Artificial  Intelligence,  Vol.  2,  Nos.  3 ami  \,  Noi  lli-Hollaml  Publishing  Co., 
Amsterdam,  1971,  pp.  189-208,  ami  a lalcr  paper  by  Kikrs,  I’ricr  Marl  ami  Nilsson,  "beaming 
anil  Kxcciilmp  (Irnrr.iliy.cil  Robot  Plans,"  in  Artificial  Intelligence,  Vol.  3,  1972,  pp.  251-288. 

1,1  C.  A lb  lloarr,  "An  Axiomatic  Basis  for  Computer  Propramminp,"  Communications 
of  the  ACM,  Vol.  12,  No.  2,  pp.  576-583. 
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tlic  system  will  fail  to  reach  state  Q In  Hoare’s  notation,  all  that  is 
implied  is  that  if  the  system  finishes  the  stated  computation,  then  Q 
will  be  true. 

2 With  state  deltas,  the  segment  of  program  executed  is  implicit  in  the 
precondition  and  is  not  explicitly  listed.  No  distinction  is  made 
between  control  and  data.  In  Hoare’s  notation,  the  segment  of  the 
program  that  is  executed  is  listed  explicitly.  The  flexibility  provided 
by  my  notation  permits  the  user  to  move  the  boundary  between 
"control"  and  "data"  whenever  he  chooses.  Moreover,  induction  over 
computation  sequences  requires  no  special  rules;  normal  mathematical 
induction  may  be  applied  in  all  circumstances. 

3.  With  state  deltas,  the  effects  of  the  computation  are  bounded  by  the 
list  of  places  modified. 


2.8T  The  frame  axiom 


In  their  axiom  system  for  characterizing  program  behavior,  Igarashi,  London  and 
L.uckham  extend  Iloarc’s  rules  to  a variety  of  syntactic  forms  found  in  programming 
languages.1*’  1-or  procedures,  a "frame  axiom"  is  introduced.  The  content  of  their  frame 
axiom  is  simply  if  P is  a predicate  which  is  true  before  procedure  Proc  is  entered,  and  if 
P and  Proc  have  ro  variables  in  common,  then  P will  continue  to  be  true  when  Proc  is 
exited.  This  axiom  provides  some  leverage  for  reasoning  separately  about  the  part  of 
the  state  that  has  changed  during  a segment  of  computation  and  the  part  that  has  not. 
However,  the  axiom  is  restricted  to  procedure  calls  and  is  not  applicable  to  bodies  of 
loops  or  alternative  paths  in  a conditional  statement  At  present,  1 don’t  believe  that 
any  program  verification  system  based  on  the  I-loyd-Hoare  system  makes  use  of  the 
frame  axiom  or  anything  similar  to  avoid  processing  the  entire  state  vector  at  every 
juncture. 


^ Shif'rru  Iparasln,  Halpli  l.omlon  ami  David  l.uckliain,  "Aulomatic  Propram 
Verification  I:  A l.opiral  Basis  ami  lls  Implcmriiiahoii,"  Acta  Informatica,  Vol.  4,  No.  2, 
pp.  145-18?.. 


?8.5  Intermittent  assertions 


More  recently,  Manna  and  VValdinger  have  taken  an  idea  presented  by  Burstall 
and  constructed  the  notion  of  intermittent  assertions Intermittent  assertions  are  very 
close  in  spirit  to  state  deltas.  For  higher  level  language  programs  in  which  the  code  is 
pure  and  effectively  d,r-ioint  from  the  data,  intermittent  assertions  correspond  to  state 
deltas  in  which  the  environment  clause  points  to  just  the  code  and  the  modification  list 
points  to  all  of  the  data.  Intermittent  assertions  provide  the  same  power  to  prove 
termination  as  state  deltas,  but  provide  no  difference  in  representation  of  state 
information  from  the  usual  inductive  assertion  technique  introduced  by  Floyd. 

The  term  “intermittent"  refers  to  a slightly  different  point  of  view  about  execution 
histories.  In  their  treatment  of  intermittent  assertions,  the  pre-  and  postconditions  are 
divided  into  two  parts  One  part  is  a special  predicate  At  which  specifies  (effectively) 
the  value  of  the  program  counter.  The  other  component  is  a general  predicate  that 
specifies  all  of  the  other  relationships  that  have  to  hold.  Under  this  dichotomy,  Manna 
and  VValdinger  take  the  point  of  view  that  the  general  predicate  holds  sometimes  when 
the  program  counter  has  the  right  value.  Accordingly,  they  say  "if  at  sometime  when 
the  program  is  at  L | F'  is  true,  then  sometime  the  program  will  be  at  L.o  and  Q will  be 
true"  This  is  fully  equivalent  with  our  formulation.  For  most  applications,  the  general 
predicate  associated  with  a particular  place  will  always  be  true  when  control  reaches  that 
point.  However,  in  some  applications,  different  predicates  will  be  true  at  different  times 
when  control  reaches  the  same  point  in  the  program  This  latter  concept  is  just  as  easily 
expressed  in  the  state  delta  formulatun  as  it  is  in  intermittent  assertions,  although  the 
point  is  emphasized  more  dearly  with  intermittent  assertions. 


1 7 - H n 

1 1 Pnisi.tll's  paper  is  ’Propiain  Proving  as  Hand  Simulation  with  a l.ililc  Induction," 
published  m Information  Processing  1974,  Proceedings  of  the  HIP  Congress, Norlh-Holland 
Pnhlishin/t  Co.,  Amsterdam,  pp.  308-312.  Zoliar  Manna  and  Rieliard  Walduipcr’s  paper 
mlroduees  the  lenn  "lUlerinillenl  assertions"  and  will  appear  in  the  Communications  of  the 
ACM,  with  I lie  mle  "Is  ’Soineiune’  Sometimes  Heller  than  ’Always’?  Iniermitlenl  Assertions  in 
Piovirip  Program  Coi  reel  ness". 
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3.  The  Proof  System 


Wc  arc  now  ready  to  look  at  the  complete  structure  of  the  proof  system  The 
purpose  of  the  proof  system  is  to  check  proofs  about  the  operation  of  programs  or  pieces 
of  programs.  Statements  about  the  operation  of  a program  are  expressed  as  state  deltas, 
and  we  can  assume  that  all  theorems  to  be  proven  are  in  this  form.  Since  state  deltas 
degenerate  into  normal  conditionals  when  the  mod  and  env  clauses  are  empty  and  all  of 
the  predicates  in  the  pre-  and  postconditions  are  support-free,  the  proof  system  contains 
all  the  power  of  a standard  proof  system  for  first-order  predicate  calculus***  and  could 
be  used  for  that  purpose.  However,  most  of  the  machinery  in  this  system  is  geared  to 
the  proof  of  SDs,  and  we  can  assume  that  it  is  used  only  to  prove  SDs. 

The  general  method  of  proving  things  is  to  enter  a series  of  hypotheses  into  the 
proof  system  which  define  the  machine,  list  the  code  and  define  the  initial  state,  and 
then  to  enter  a scries  of  commands  which  advance  the  state  of  the  machine  until  the 
final  state  is  reached.  Other  actions  are  required  for  case  analysis  and  induction 
through  loops 

The  proof  system  is  divided  into  two  main  sections,  a checker  and  a proposer. 
The  checker  maintains  a symbolic  snapshot  of  the  state  of  the  machine,  augmented  by 
various  theorems  and  declarations  The  checker  is  driven  entirely  by  commands  it 
receives  from  the  proposer.  The  checker  examines  each  command  to  see  if  it  is  well- 
formed  and  applicable  to  the  current  state.  If  the  command  is  well-formed  and 
applicable,  the  checker  executes  the  command  by  updating  its  internal  state.  The  only 
direct  output  from  the  checker  is  a signal  back  to  the  proposer  indicating  whether  or  not 
the  command  worked.  However,  the  checker’s  lists  of  known  theorems  and  state 
information  is  accessible  to  the  proposer  for  examination. 

The  role  of  the  proposer  is  to  suggest  reasonable  next  proof  steps.  It  may  do  so 
based  on  heuristics,  by  asking  the  user  or  by  reading  a prepared  proof  from  a file. 
Regardless  of  where  the  proof  steps  originate,  the  proposer  send*  each  step  to  the 
checker  to  cause  the  checker  to  update  its  internal  state. 

At  the  moment,  the  proposer  contains  no  heuristics.  Thus  it  is  simply  a small 


***  If  the  precondition  is  also  empty,  the  SI)  is  equivalent  to  the  conjunelion  of  the 
predicates  in  the  posieondilion,  with  whatever  quanlifieation  is  required  in  the  vars  clause. 
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executive  routine  for  obtaining  information  from  the  user  and/or  pulling  in  prepared 
proofs  from  files.  Possible  extensions  to  the  proposer  arc  discussed  in  chapter  six. 

1 lie  checker  is  recursive.  During  any  proof,  a new  subproof  may  be  started. 
When  that  subproof  is  complete,  the  newly  proven  SD  is  added  to  the  list  of  known 
tlieoicms  in  the  original  proof. 


3.1  Contexts 


Within  a subproof,  the  internal  state  of  the  checker  is  called  a context.  The 
primary  components  of  a context  arc  a list  of  predicates  which  describe  the  current  state 
of  the  machine,  a list  of  names  which  arc  "in  use",  either  as  place  names,  as  variables,  or 
both,  and  a map  of  the  overlap  relationships  among  the  various  places.  Two  other  lists 
of  places  play  an  important  role  in  connecting  lower  level  contexts  to  higher  level 
contexts.  They  are  the  list  of  places  which  may  be  modified  and  the  environment  list. 

A new  context  is  created  when  a new  subproof  is  begun  and  is  destroyed  when 
the  subproof  is  complete  Many  of  the  components  of  the  context  are  initialized  to  the 
current  value  of  the  corresponding  component  of  the  superior  subproof.  In  principle, 
the  new  context’s  components  arc  copies  of  the  old  context’s  components  However,  one 
of  the  goals  in  the  design  of  the  system  is  to  minimize  the  copying  of  constant 
information,  and  with  one  exception  the  initial  values  for  the  new  context  are  formed 
simply  by  setting  up  a pointer  to  the  current  value  in  the  upper  context.  The  exception 
will  emerge  in  the  discussion  below. 


3. 1 I USABl  E 


The  most  important  component  of  a context  is  the  list  of  accessible  predicates. 
This  list  is  called  USAE1LE  Conceptually,  four  different  kinds  of  predicates  cohabit  this 
list: 

I state  predicates 

These  predicates  constrain  the  values  stored  in  the  places.  Since  the  machine  state 
must  satisfy  all  of  these  predicates,  their  conjunction  is  the  current  state 
description. 


2. 


state  deltas 


These  predicates  describe  what  changes  to  the  state  may  take  place  by  forward 
execution  of  the  machine.  The  precondition  of  the  SD  determines  when  the  SD  is 
applicable,  so  the  mere  appearance  of  the  SD  on  USABLE  does  not  guarantee  that 
the  SD  will  ever  be  useful. 

3.  place  relationships 

These  predicates  relate  sets  of  places  to  each  other.  The  key  relationships  of 
interest  are  that  two  or  more  places  are  disjoint  from  each  other  and  that  a set  of 
places  is  a decomposition  of  another  place.  These  two  relationships  are 
summarized  in  the  predicate 

(Covering  P0  <Pj  ...  Pk>) 

which  states  that  P^  ...  Pk  are  pairwise  disjoint  and  that  each  is  contained  in 
p0.  Place  relationships  are  also  stored  in  the  place  graph,  described  below. 

i.  general  facts 

Definitions  of  basic  terms  and  various  lemmas  are  often  needed  in  the  course  of  a 
proof.  These  predicates  are  not  specific  to  the  state  of  the  machine,  or  even  to  the 
notion  of  computation.  For  example,  the  definition  of  factorial  or  the  definition 
of  ordered  fall  into  this  category. 

Since  any  two  predicates  on  this  list  may  be  combined  to  form  a conjunction,  these 
categories  arc  not  rigorous.  However,  the  proof  system  does  not  try  to  classify  the 
predicates  according  to  these  categories.  Each  command  executed  by  the  checker  has  its 
own  criterion  for  applicability. 

All  predicates  on  USABLE  are  cross-referenced  according  to  the  places  they  depend 
upon.  The  purpose  of  the  cross-referencing  is  to  be  able  to  find  and  delete  any 
predicate  which  depends  upon  a place  which  has  been  modified  (or  is  assumed  to  have 
been  modified.) 

The  mechanism  for  cross-referencing  the  predicates  is  the  following.  Whenever  a 
predicate  is  added  to  the  USABLE,  it  is  analyzed  syntactically  to  determine  the  list  of 
places  which  support  it  The  intent  is  that  a predicate  should  be  left  on  the  list  until 
the  value  stored  in  a supporting  place  is  changed.  For  example  . A=0  is  supported  by  A 
and  .Ai.6^0  is  supported  by  A and  B.  The  precise  rule  for  computing  support  for  a 
predicate  was  discussed  in  chapter  two. 
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After  computing  the  support  of  a predicate  which  is  to  be  added  to  USABLE,  the 
predicate  is  added  to  USABLE  and  it  is  also  added  to  the  piedrcau  list  of  every  one  of 
the  places  in  its  support  The  predicate  lists  are  part  of  the  graph  structure  maintained 
for  places 

USABLE  is  implemented  as  a list  of  predicate  records.1*^  Each  predicate  record  has 
a flag,  exp,  env  and  p I ace  list  component.  The  exp  component  is  the  actual 
predicate  place!  ist  is  the  list  of  supporting  places,  flag  and  env  are  explained 
below.  The  initial  value  of  USABLE  is  a selected  subset  of  the  predicates  on  the  copy  of 
USABLE  in  the  superior  context,  augmented  by  the  precondition  of  the  SD  to  be  proven. 
The  details  of  the  selection  process  are  discussed  below. 


3.1.2  FREE 


FRFF  is  the  set  of  variable  names  which  appear  free  in  formulas  in  the  proof.2'^ 
When  a new  subproof  is  started,  any  variables  in  the  van  clause  of  the  SD  to  be  proven 
are  added  to  FRFF.  (They  must  not  appear  there  beforehand,  of  course.)  Similarly, 
when  a new  variable  name  is  assigned  to  a value  through  the  1 nstant  i ateContents 
command,  that  name  is  adeed  to  FREE. 


3.1.3  Places 


One  of  the  goals  of  this  system  is  to  provide  an  efficient  method  for  treating 
aliasing  and  overlap  among  places  In  contrast  to  most  verification  systems,  we  do  not 
assume  that  different  place  names  refer  to  different  places.  However,  most  place  names 
do,  in  fact,  refer  to  different  places,  so  we  need  a way  of  determining  the  clash  (or 
potential  dash)  among  place  names  reasonably  efficiently. 


^ "Itreord"  is  a d.ua  structure  in  Inlrrlisp.  Hrcorils  have  a fixed  number  of 
eoirrporrenls,  accessible  hy  field  rrarrres.  Each  component  may  he  aecessed  and/or  modified 
separately. 

In  lliis  chapter,  "FRFF"  refers  only  lo  a eomponent  of  the  context  of  a suhproof  and 
is  completely  unrelated  to  the  IMP  code.  I apolopi/.c  for  the  confusion. 
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The  place  system  maintains  a database  of  relations  among  the  various  place 
names  and  is  consulted  whenever  the  checker  needs  to  know  all  possible  overlaps  among 
a set  of  names  The  place  system  is  also  consulted  whenever  it  is  necessary  to  check  that 
a set  of  place  names  refers  to  completely  disjoint  places. 

The  key  data  structure  in  the  place  system  is  the  place  graph.  The  place  graph 
contains  two  types  of  nodes,  place  nodes  and  family  nodes.  Place  nodes  are  connected 
only  to  family  nodes  and  family  nodes  are  connected  only  to  place  nodes.  The  arcs  are 
directed  and  the  graph  is  acyclic,  so  the  notions  of  "up"  and  "down”  are  well  defined. 
Each  family  node  contains  exactly  one  arc  going  up  to  a place  node,  but  may  contain 
any  number  (but  at  least  one)  of  arcs  going  down  to  a place  node.  Place  nodes  may 
have  any  number  of  arcs  going  in  either  direction,  including  none.21 

The  place  graph  encodes  relationships  of  the  form 

(Covering  Pg  <Pj  ...  P^>) 

A relationship  of  this  kind  is  a family  and  is  encoded  as  a single  family  node  in  the 
place  graph.  Pp  is  called  the  mother  of  the  family  and  each  of  the  Pj  are  daughters. 

Each  place  node  is  implemented  as  a record  with  the  following  components: 


names 

The  names  of  the  places  associated  with  this  place 
node  Multiple  names  are  synonyms 

f lag 

A space  for  marking  whether  this  node  has  been  seen 
during  a traversal.  In  between  calls  to  the  place 
system,  the  flag  is  NIL. 

mother f ami  1 ies 

A list  of  family  nodes  in  which  this  place  node  is  a 
daughter. 

daughter fami 1 ies 

A list  of  family  nodes  in  which  this  place  node  is  the 
mother. 

2'  The  idea  of  using  lwo  types  of  nodes  in  lhe  place  graph  is  due  lo  Dave  Wile.  Prior 
lo  li is  suggestion,  I hail  been  struggling  wiih  a ginpli  slruelurc  wilh  only  place  node*;  and 
conned  ions  union/'  lhe  nodes  in  lhe  form  of  lisis  of  lists.  Afier  switching  to  explicit 
rcprescntal ion  of  lhe  families,  lhe  lravcrsing  algorithms  became  clear.  Since  the  traversing 
algorithms  make  use  of  lhe  family  nodes  as  more  llian  simple  lisis  of  lists,  explicit 
representation  of  lhe  family  nodes  was  a critical  slep  in  formulating  the  ideas. 


predlist  The  list  of  predicates  (in  all  contexts)  which  are 

supported  by  this  place. 

Kadi  family  node  is  implemented  as  a record  with  the  following  components: 

flag  A space  for  marking  whether  this  node  has  been  seen 

during  a traversal.  In  between  calls  to  the  place 
system,  the  flag  is  NIL. 

mother-place  The  place  node  for  the  mother  of  this  family. 

daugh terp laces  A list  of  the  place  nodes  for  the  daughters  in  the 
family. 


3.1.4  not.  and  SUPPRFSS 


When  a subproof  is  begun,  one  of  the  parameters  supplied  is  a list  of  places 
which  may  tc  modified  during  the  course  of  the  proof.  This  list  is  accessible  during  the 
proof  as  M.iU  Commands  which  attempt,  to  modify  the  contents  of  a place  first  check. 
MOtl.  Whcr  tic  subproof  is  complete,  MGU  becomes  the  mod  clause  in  the  proven  SD. 

When  a subproof  is  started,  the  predicates  that  arc  accessible  in  the  new  context 
include  a s',  b: ct  of  the  predicates  from  the  higher  context.  If  these  predicates  are 
constant  for  (h?  life  of  the  subproof,  no  copying  is  required  and  they  may  be  accessed 
directly.  Nov  ccr,  predicates  which  arc  attached  to  places  that  may  be  modified  must 
be  moved  ou1  of  the  way  and  restored  when  the  subproof  is  complete;  this  applies  to  all 
predicates  attached  to  modifiable  places  irrespective  of  whether  these  predicates  will  be 
used  at  the  lov  er  level 

The  predicate;  arc  moved  out  of  the  way  by  adding  them  to  a list  called 
SUITRESS.  Wh  n the  subproof  is  complete,  the  predicates  on  SUPPRESS  are  put  back 
onto  USABLE.  In  the  current  implementation,  predicates  arc  not  physically  removed  from 
USABLE  during  his  process;  a flag  attached  to  the  predicate  is  set  to  mark  it  as 
unavailable.  Wl  en  the  subproof  is  finished,  the  flag  is  reset  This  mechanism  was 
adopted  to  permi’  he  proposer  to  keep  pointers  into  the  list  of  accessible  predicates; 
when  the  "suppr  s; ed”  flag  is  set,  routines  in  the  proposer  would  know  that  that 
predicate  is  not  a ti  ally  available,  although  it  will  be  available  iatf-r  when  the  prior 
context  is  rcstoicd  i he  proposer  docs  not  yet  take  advantage  of  this  capability. 
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3. 1.5  ENV 


In  addition  to  the  list  of  places  which  may  be  modified,  another  list  of  places  is 
also  supplied  when  a subproof  is  begun  and  maintained  during  the  proof  as  ENV.  ENV 
is  a list  of  places  whose  values  are  brought  down  from  the  immediately  superior  context 
and  made  available  in  the  new  context.  Since  values  are  represented  only  by  the 
predicates  on  USABLE  which  reference  them,  "bringing  down  the  values"  translates  Into 
bringing  down  the  predicates  whose  support  is  entirely  contained  within  ENV.  Predicates 
whose  support  is  partly  but  not  wholly  within  ENV  are  not  brought  down.  Note  that 
predicates  which  do  not  depend  upon  any  place  are  always  brought  down,  even  when 
ENV  is  null. 

If  ENV  and  NOD  arc  disjoint,  predicates  on  USABLE  in  the  superior  context  whose 
support  is  entirely  contained  within  the  places  on  ENV  are  not  actually  copied  to  the  new 
context  Whenever  they  arc  referenced,  the  place  system  is  called  to  see  that  the  higher 
level  predicates  are  legally  visible  in  the  lower  context. 

If  ENV  and  NOD  intersect,  predicates  whose  support  is  entirely  contained  within  ENV 
and  whose  support  is  at  least  partially  within  N00  are  actually  copied  to  the  new  context 
and  the  flap  component  of  the  original  copy  of  the  predicate  is  set  to  T to  mark  the 
predicate  as  inaccessible  When  the  subproof  is  complete,  the  flag  is  reset  to  NIL,  and 
the  predicate  becomes  accessible  ir  its  own  context  again 

Further  details  of  the  algo  ithms  which  bring  down  predicates  according  to  ENV 
arc  given  below 

When  complete,  the  ENV  becomes  the  env  clause  of  the  returned  SD. 


3.1.6  Ancillary  components 


Two  additional  components  complete  the  implementation  of  a context.  SDGOAL 
holds  a copy  of  the  entire  SD  to  be  proven  and  GUAL  holds  a copy  of  the  postcondition 
of  the  SD  to  be  proven  SDGOAL  is  not  referenced  during  the  course  of  the  subproof. 
When  the  subproof  is  complete,  the  SD  that  is  added  to  the  superior  context  comes  from 
SDGOAL 

GOAL  is  used  only  slightly  during  a subproof.  When  the  Close  command  is 
executed,  USABLE  is  examined  to  sec  if  the  postcondition  stored  in  GOAL  is  currently  true. 
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At  some  future  point,  It  is  contemplated  that  the  proposer  may  be  able  to  make  use  of 
GOAL  to  dcteiminc  which  command  to  send  to  the  checker. 


3.2  The  checker 


Commands  from  the  proposer  fall  into  five  main  classes:  opening  or  closing 
subproofs,  advancing  the  computation,  adding  new  place  relationships,  combining 
aspects  of  the  current  state,  adding  definitions  of  new  terms. 

The  checker  is  divided  into  three  subcomponents,  the  kernel,  the  place  system  and 
the  simplifier.  T he  kernel  receives  the  commands  from  the  proposer,  checks  each  one 
for  applicability  and  makes  the  appropriate  changes  to  the  context.  Whenever  one  of 
these  actions  requires  knowledge  of  the  relationships  among  the  places,  the  place  system 
is  consulted.  Whenever  a new  predicate  is  added  to  the  state  description  or  whenever 
the  kernel  needs  to  know  if  a predicate  is  true,  the  simplifier  tries  to  reduce  the 
predicate. 

The  remainder  of  this  section  describes  the  commands  currently  implemented. 
For  each  command,  there  is  a series  01  conditions  which  are  checked  before  any  action  is 
taken.  If  the  command  is  not  recognized  or  if  one  of  the  checks  fails,  no  action  is  taken 
and  the  kernel  returns  NIL.  If  the  check:  succeed,  the  context  is  modified  (or  created  or 
destroyed)  according  to  the  rules  given  below.  The  kernel  then  returns  with  a non-NIL 
response. 


3.2.1  Opening  and  closing  subproofs 


A new  subproof  is  initiated  by  the  (Open  pre  mod  env  post  vars)  command, 
where  pre,  mod,  env,  post,  and  vars  are  the  components  of  the  new  SL)  to  be  proven. 

The  variables  in  the  vars  clause  must  not  be  in  use,  i.c.,  none  of  them  may  be 
members  of  FUEL.  The  places  in  mod  must  all  be  registered  in  the  place  system.  If 
cither  of  these  checks  fails,  no  action  is  taken  and  NIL  is  returned 

After  these  checks  are  passed,  a new  context  is  created. 

The  old  value  of  FUEL  is  saved  and  then  FliFE  is  augmented  with  the  variables  in 


vars. 


The  old  value  cf  MOD  is  saved  and  then  MOD  is  set  to  mod. 

The  old  values  of  SUPPRESS  and  USABLE  are  saved  and  then  SUPPRESS  is  set  to 
NIL. 

ENV  is  augmented  by  env  and  this  new  value  is  put  at  the  top  of  ESTACK. 
(OMEGA)  is  then  pushed  onto  ESTACK. 

All  predicates  which  are  supported  by  any  of  the  places  listed  in  mod  or  by  places 
which  overlap  with  mod  are  added  to  SUPPRESS  and  marked  as  suppressed. 

Predicates  on  SUPPRESS  whose  support  is  entirely  contained  within  the 
environment  are  added  to  USABLE. 

Predicates  in  pre  are  also  added  to  USABLE. 

A copy  of  the  pre  mod  env  post  and  vars  clauses  is  kept  in  SDGOAL. 

Finally,  PuchP  I occSys  is  called  to  prepare  the  place  system  for  new  declarations. 

A subproof  is  terminated  by  the  (Close)  command.  The  only  check  Is  whether 
the  predicates  in  the  pre  clause  in  the  corresponding  Open  command  are  all  on  USABLE. 
If  they  are,  the  old  context  is  restored  and  the  new  SD  is  added  to  It. 


3?.2  Advancing  the  computation 


Only  one  rule  is  implemented  for  advancing  the  computation,  (ApplylnstSD  patt 
varlist) . ApplylnotSU  instantiates  a SD  on  USABLE  and  applies  it  to  the  current  state. 
patt  is  an  Intcrlisp  pattern  which  is  matched  against  USABLE  to  find  a SD  to  apply.  See 
chapter  five  for  examples  of  patterns. 

varlist  is  a list  of  variables  and  terms  in  property  list  format.  The  terms  are  to  be 
substituted  for  the  variables. 

Several  checks  are  made  before  taking  any  action. 

patt  must  match  a SL)  on  USABLE. 


varlist  must  match  the  vars  component  of  the  SD. 


All  of  the  substitutions  must  be  proper. 


The  mod  component  of  the  SL)  must  be  entirely  contained  within  MOD. 

All  of  the  predicates  in  the  precondition  must  be  on  USABLE 

If  all  of  these  checks  succeed,  predicates  supported  by  places  which  overlap  with 
the  mod  list  of  the  SD  arc  deleted  from  USABLE  and  then  the  predicates  in  the 
postcondition  are  added. 


3.?.3  Entering  new  placcnamcs 


Three  commands  are  available  for  adding  new  names  to  the  place  system. 
(NcunecompoG  i t i on  (Covering  ...))  adds  a family  to  the  place  graph  when  the 
mother  place  is  already  registered  and  the  daughter  places  are  not.  Each  of  the 
daughters  is  added  to  the  list  of  all  registered  places  and  a family  node  and  a set  of 
place  nodes  arc  added  to  the  place  graph.  The  whole  relationship  is  also  added  to 
another  list  to  keep  track  of  what  additions  to  the  place  graph  have  taken  place  during 
tins  subproof  When  the  subproof  is  complete  and  has  been  closed,  these  relationships 
are  deleted  and  the  place  system  is  restored  to  its  previous  state. 

(NcuComposi  t ion  (Cove- inci  ...))  also  adds  a family  to  the  place  graph.  In 
this  ease,  however,  the  daughters  must  all  be  registered  and  the  mother  must  not  be. 
While  the  NcuUecompoo  i 1 1 on  command  requires  that  the  Cover  ing  relationship  be 
accessible  within  the  current  context,  the  requirements  for  the  NcuCompos  i t i on 
command  arc  somewhat  stiffer.  All  of  the  daughters  listed  in  the  covering  relationship 
must  be  known  to  be  disjoint  within  the  place  system.  T he  place  system  is  very 
conservative  about  disjointness,  and  it  can  happen  that  a set  of  places  can  be  proven  to 
be  disjoint  by  manipulation  of  the  (Covering  ...)  predicates  within  the  proof  system, 
while  the  algorithms  of  the  place  system  declare  that  overlap  is  possible.  For  example,  if 
(Covering  A <B  C>)  and  (Covering  A <U  E>)  arc  two  relationships  that  have  been 
entered  into  the  place  system  using  the  NeuUecompos  i t i on  rule,  the  place  system  will 
assume  that  B and  C each  overlap  with  D and  E.  At  a later  time,  it  may  be  discovered 
that  B and  0 aic  equal  and  that  C and  E arc  equal,  thus  eliminating  two  of  the  four 
possible  overlaps  The  place  system,  however,  cannot  accept  this  information  and  is 
committed  to  believing  that  all  of  the  overlaps  aic  possible.  The  reason  for  this 
restriction  lies  in  the  representation  used  In  the  place  graph  The  place  graph  consists 
of  a set  of  connections  among  the  places  'l  ire  algorithms  which  search  the  graph  are 
based  on  the  idea  that  if  another  place  is  reached  at  any  time  during  a search,  then  that 
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place  may  overlap  with  the  original  place.  Adding  new  links  to  the  graph  could  only 
have  the  effect  of  showing  that  places  not  previously  thought  to  overlap  actually  do 
overlap.  Since  this  particular  kind  of  change  implies  that  predicates  which  were 
retained  during  a computation  should  have  been  deleted,  even  this  change  is  ruled  out. 
In  summary,  once  the  place  system  registers  a place,  the  relationships  of  that  place  with 
all  other  currently  registered  places  is  fixed.  NeuComposi t ion,  therefore,  must  check 
that  all  of  the  daughters  are  known  by  the  place  system  to  be  disjoint. 

The  last  command  to  enter  new  place  names  is  (LnterSynonym  Pj  P2).  Pj  must 
already  be  registered  and  Pp  must  be  new.  1 he  name  Pp  is  simply  added  to  the  list  of 
names  in  Pj’s  node.  In  an  earlier  implementation,  this  facility  was  not  provided.  As  a 
consequence,  equality  relationships  were  represented  in  terms  of  one  place  covering  the 
other.  At  certain  points  in  the  proof,  it  became  necessary  to  show  that  one  of  the  points 
covered  the  other,  while  at  other  times  it  was  necessary  to  show  the  reverse.  The 
structure  of  the  place  graph  forced  an  ordering  between  the  places  and  prevented 
demonstration  that  each  covered  the  other. 


3.2.4  Normal  derivations 


The  commands  in  this  section  derive  consequences  from  the  predicates  in  the 
current  context.  The  computation  is  not  advanced  and  the  place  graph  is  not  affected. 
Except  in  the  case  of  the  Substi  tutc  command,  predicates  added  to  the  current  context 
arc  simplified  according  to  the  following  rules  in  the  next  section: 

(Combinc-Caccs  pattj  pattp)  takes  two  SDs  and  combines  them  into  a single  SD. 
The  pre-  and  postconditions  of  the  new  SI)  are  the  disjunctions  of  the  pre-  and 
postconditions,  respectively,  of  the  two  existing  SDs  T he  modification  and 
environment  lists  are  the  unions  of  the  modification  and  environment  lists, 
respectively  of  the  two  existing  SDs.  The  vars  list  of  the  existing  SDs  must  be 
empty 

(InstantiatcContcnts  placename  variable)  adds  . placename^vanable  to  the 
current  context  provided  variable  is  new. 

(ForSomc  varslist  pied  substlist ) adds  (FS  varslist  pied)  to  the  current  context 
provided  there  is  a predicate  already  in  the  current  context  which  is  equal  to  the 
result  of  substituting  the  terms  in  substlist  for  the  variables  in  varslist.  All  of  the 
substitutions  must  be  proper  substlist  is  in  property  list  format 
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(Substitute  new  old  patt)  locates  both  a predicate  which  matches  patt  and  the 
[Medicate  new- old.  The  term  new  is  then  substituted  for  old  in  the  predicate 
matching  patt  and  the  result  added  to  the  current  context  without  simplification. 
The  old  predicate  is  not  deleted. 

(SimpIcFval  patt  I forces  the  predicate  located  by  patt  back  through  the 
simplification  routines.  The  most  common  use  for  this  command  is  reprocess  an 
if-thcn-else  expression  after  the  "if"  part  has  been  specified. 

(SuapOOTSEL  exp  patt ) substitutes  an  expression  of  the  form  (SEL  (DOT  a)  <>) 
for  an  expression  of  the  form  (DOT  (SEL  a b))  and  then  simplifies,  exp 
must  be  an  expression  of  the  form  (DOT  (SDL  a 6))  appearing  in  a predicate  in 
the  current  context  located  by  patt.  The  substitution  of  (SEL  (DOT  a)  b ) usually 
makes  it  possible  to  evaluate  the  term  completely. 

(SwapOOTcccithru  exp  patt ) is  similar  to  SnapDOTSEL  except  that  exp  must  be  an 
expression  of  the  form  (DOT  (segthru  a b) ) and  it  is  replaced  by  (segthru 
(DOT  a)  b). 

(Over  I imit  exp  patt)  examines  exp  to  see  if  it  can  be  shown  to  be  zero.  If  so, 
all  occurrences  of  exp  in  the  predicate  located  by  patt  are  replaced  by  zero,  exp 
must  be  of  the  form  (SEL  ex  pi  n) , where  n is  an  integer  and  the  current  context 
has  knowledge  that  expl  is  less  than  2n. 

(Under  I imit  exp  patt)  expects  exp  to  be  of  the  form  (segthru  expl  n ) , where 
n is  an  integer.  If  the  current  context  contains  knowledge  that  expl  is  less  than 
?n,  then  expl  is  substituted  for  exp  in  the  predicate  located  by  patt. 

(Make i ndexof  exp  patt)  looks  for  (EQ  c (SEL  a exf))  or  (EO  (SEL  a exp)  c) 
in  the  current  context.  If  cither  form  is  found,  lindoof  c a)  is  substituted  for 
exp  in  the  predicate  located  by  patt. 

(Derive  exp)  simplifies  exp  and  adds  it  to  the  current  context.  This  command 
directly  violates  the  integrity  of  the  proofcliccker,  since  no  checking  is  performed 
to  make  sure  that  exp  is  derivable  from  the  other  predicates  in  the  current 
context  This  command  is  used  as  a temporary  expedient  to  skip  over  derivations 
that  are  not  yet  supported  by  the  proof  system  but  appear  (to  the  user)  to  be 
sound  Naturally,  proofs  containing  Derive  commands  are  not  considered 
complete. 
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32.5  Simplification 


As  noted  above,  except  in  the  case  of  the  Substitute  command,  before  a 
predicate  is  added  to  the  current  context,  it  is  simplified.  The  simplification  rules 
currently  in  use  are  the  following. 

If  a form  is  atomic,  no  further  simplification  is  attempted. 

If  a form  is  not  atomic,  its  arguments  are  simplified  before  an  attempt  is  made  to 
simplify  the  form  itself. 

If  the  form  is  headed  by  an  arithmetic  operator  and  the  (simplified)  arguments 
are  numbers  instead  of  symbolic  expressions,  the  indicated  arithmetic  is 
performed. 

If  the  form  is  headed  by  SEL,  segthru  or  segfrom  and  if  the  arguments  are 
numbers,  the  indicated  operation  is  performed  If  the  first  argument  is  of  the 
form  (DOT  x),  the  DOT  is  moved  to  the  outside  and  the  form  is  returned;  pushing 
the  DOT  to  the  outside  minimizes  the  support. 

In  some  cases  involving  application  of  two  selection  operators,  it  is  apparent  that 
one  of  them  is  redundant.  The  cases  that  are  implemented  are 

(SET  (segthru  x y)  z)  =>  (SET  x 7),  if  z<y; 

( rey thru  (segthru  x y)  z)  r>  (segthru  x u),  where  u = min(y.z). 

If  the  form  is  headed  by  DOT,  an  attempt  is  made  to  evaluate  it  by  looking  in  the 
current  context.  If  this  fails,  but  the  argument  is  headed  by  SET,  segthru  or 
segfrom,  this  operator  and  the  DOT  are  commuted  and  the  current  context  is 
again  consulted.  This  process  is  designed  to  evaluate  forms  such  as  5 DOT  (SEL 
GFFIFE  IS))  when  the  current  context  is  holding  a value  for  all  of  GFREE  but  not 
explicitly  for  GFREE  = 15.  When  the  process  of  pushing  the  DOT  in  and  looking  up 
a value  has  completed,  the  resulting  form,  whether  or  not  an  evaluation  has  been 
successful,  is  resimphfied  in  accordance  with  the  above  rules  for  SEL,  segthru 
and  segfrom.  For  forms  which  were  not  evaluated,  and  thus  were  left  with  an 
embedded  DOT,  rcsimplification  results  in  the  DOT  being  moved  back  out.  For 
forms  which  were  evaluated,  resimplification  selects  out  the  component  of  interest. 

”1  f"  statements  are  simplified  if  the  antecedent  can  be  simplified  to  either  T or 
NIL 


Arrai|»x/Array  is  simplified  to  just  x.  Similarly,  Array-  (PI  ace/Array)  is 
simplified  to  just  Place.  Note  that  in  the  first  ease,  x is  a selector  into  the  list 
Array,  while  in  the  second  case,  Place  is  a placename. 


3.?.6  Definition  of  new  terms 


The  last  set  of  commands  provide  a way  of  introducing  new  predicates  to  the 
proofcheckcr.  Two  commands  are  provided,  one  for  introducing  the  syntax  of  the  new 
predicate  and  one  for  introducing  the  definition.  If  the  predicate  has  only  a prefix 
form  and  no  syntactic  extension  is  required,  no  command  is  required  for  the  syntax. 

The  command  for  introducing  new  syntax  has  the  following  format. 

(Oef incSyntax  ncuiprcd  (NEUISUORD  ' {full  English  singular  form) 

' ( partial  English  plural  form ) 

' {prefix  form) 

’ {variables) ) ) 


NP l-J I SUORD  is  a CUSP  function  and  the  body  of  this  command  is  simply 
executed.  The  details  on  the  execution  of  NEUISUORD  are  contained  in  the  Interlisp 
manual.  Examples  of  how  this  command  is  used  are  contained  in  chapter  five. 

The  command  for  defining  the  semantics  of  a new  predicate  is 

(Clef  incOperator  newpred  definition  support-rule) . 

The  support-rule  is  a pattern  used  for  computing  support  of  forms  involving  the 
new  predicate.  In  principle,  the  support-rule  should  be  checked  in  accordance  with  the 
discussion  in  chapter  two.  At  present,  however,  this  requirement  is  not  implemented. 
Examples  of  the  use  of  this  command  are  also  contained  in  chapter  five 


3.3  The  place  system 


The  place  system  is  a more  or  less  self-contained  set  of  routines  which  are  called 
from  the  kernel  at  various  points  in  the  execution  of  a command 


3.3. 1 FindPlaceNode 


F ; ndP I oceNode  is  the  function  which  translates  a place  name  Into  a place  node 
If  a simple  place  name  is  no.  registered.  NIL  is  returned,  if  F IndPlaceNode  is  given  a 
subscripted  place  name,  a potnier  to  the  node  corresponding  to  the  smallest  registe 
component  is  returned.  If  the  base  name  is  not  registered,  NIL  Is  returned. 

Place  names  are  added  to  the  hash  table  b,  the  kernel  commands 
NcuCo.posi  .ion,  NcuOecor.posi.ion  and  EntcrSpnonc,..  A record  .s  keptof  e,Cu  °{ 
the  actions  which  causes  names  to  be  added  to  the  place  list  and  node  .0  b I added  t 
the  place  graph,  and  all  of  the  actions  carried  out  during  the  course  of  a p 
undone  when  the  subproot  is  closed.  This  is  a mechanism  for  permiumg ; names 
their  overlap  relat.onsh.ps  to  exist  jus,  within  the  scope  of  a subproof  (and  its 
subproofs).  PushP  I aceSys  is  the  routine  called  b,  .he  kernel  when  a subproof  is  begun. 
PosP  I aceSyS  is  called  when  the  subproof  L complete. 


3.3.2  Traversing  algorithms 


IF indAf . ec.edPlaces  place,  ie.l  re, urns  a Us.  of  all  of  .he  place  nodes  whhth 
are  no.  guaranteed  ,o  be  disjoin,  from  .he  places  listed  (b,  name)  ,n  placehst. 

F IndAf  fectedPlaces  is  called  during  execulion  of  the  Applgl nstSO. 

tflarkP  P fpr  imcl , UlarkFH  II  and  IflarkFD  f)  are  the  basic  graph 
traversing  functions. 

h,  a call  to  For kP.  p is  a pointer  to  place  node  and  Ipri.e  is  a pointer  to  the 
famdy  node,  if  an,,  from  which  p is  being  reached.  MarkP  cheeks  .lag  m .he  plac 
node  If  . I aq  is  nor  NIL , tins  place  node  has  been  visited  already  and  no  fur.he 
act, on  IS  taken  except  to  set  C0NFL1C1FLAG  ro  T.  (C0NFL1CTFLAG  rs  checked  b, 

A I iDisjointp;  see  below.) 

If  flog  is  NIL.  it  is  set  to  T,  the  place  node  is  added  to  MARKETPLACES,  MarkFM  is 
cal,ed  for  each  of  the  families  listed  in  mother  f ami  I ies  and  MarkFD  is  called  fo 
of  the  families  listed  in  daughter  f ami . ies.  except  iter  Ite  family  fpr , me  « exempted 

from  exploration. 

HarkFtI  is  called  from  flarkP  with  a pointer  ro  a family  whrch  contains  the  place 
node  .""  daughter.  MorkFIt  checks  .lag  m the  famriy  node.  If  ihe  flag  is  ahead,  set. 
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no  fuithcr  pioccssmg  takes  place,  li  flay  is  not  ahtady  set,  it  is  now  set  and  fttarkP 
f : mo  thorp  I ace  f)  is  called  to  explore  the  mother  of  the  family  and  her  relatives.  The 
inclusion  of  f in  the  calling  sequence  to  MarkP  prevents  MarkP  from  attempting  to  re- 
explore the  graph  through  this  family,  f is  also  added  to  the  MARKEDFAMLIES  list  for 
use  by  Untlark  in  erasing  all  of  the  flags. 

MarkFtl  is  called  from  MarkP  with  a pointer  to  a family  which  contains  the  place 
node  as  a mother  HarkHI  rlirrls  (lay  in  thr  family  nodr  and  terminates  tf  tt  Is 
already  set.  If  flag  is  not  already  set,  it  is  set  now  and  f is  added  to  MARKEDPLACES. 
MarkP  is  called  for  each  of  the  places  listed  in  the  daughterplaces  component  of  the 
family.  MarkP  is  prevented  from  re-exploring  this  family  by  including  f in  the  call  to 
MarkP. 


{ A I IDisjointp  pi  ace  list)  is  used  by  NeuCompos  i t i on  to  check  if  all  of  the 
places  listed  (by  name)  in  placelist  arc  known  to  be  disjoint.22  Al  IDisjointp  is 
implemented  by  setting  CONFLICTFLAG  to  NIL,  calling  MarkP  for  each  of  the  place  nodes 
corresponding  to  a place  listed  in  placelist,  and  returning  the  value  of 
CONFLICTFLAG.  UnMark  is  called  after  the  graph  is  traversed  to  erase  all  of  the  flags 
that  had  been  set. 

(Ln t i r e I yConta i ned i np  subp I acenodes  superp I acenodes)  checks  to  see  if 
each  of  the  places  listed  in  subp  I acesnodes  is  a subplace  of  at  least  one  of  the  places 
listed  in  super p I acenames.  Ent  i re  I yConta  i ned  i np  operates  by  setting  flag  in  each 
place  node  corresponding  to  a place  named  in  superp  I acenames  and  then  calling 
Coritainedinp  for  each  of  the  nodes  listed  in  subp  I acenodes.  Containedinp  explores 
every  upward  path  either  until  it  encounters  a marked  place  node  or  until  all  paths 
have  been  exhausted  If  a marked  place  is  encountered,  Containedinp  returns  T; 
otherwise  it  returns  NIL  Ent  ire lyConta ined inp  returns  T if  each  of  its  calls  to 
Containedp  returned  T;  otherwise  it  returns  NIL. 

En t i r e I uCon ta i ned  i np  is  called  to  determine  if  the  support  for  a particular 
predicate  is  entirely  within  the  set  of  places  which  form  the  environment  for  the 
subproof  which  is  immediately  subordinate  to  the  proof  in  which  the  predicate  was 
created.  If  so,  the  predicate  is  considered  "visible"  and  is  available  for  use  In  all 
subordinate  subproofs 


""  Aficr  I firsi  coilrd  Alldisjomip,  I re-examined  NcwCompositioii  and  revised  it  to 
require  only  a C.ovonnp  predicate  similar  lo  NetvDreoin  position.  hater,  1 discovered 
Alldisjointp  was  uoi  used  anywhere.  I let  the  mailer  sei  for  a while.  Hod  Hurstall  eaine  by  and 
examined  the  prapli  structure.  As  the  result  of  that  discussion,  I re-examined  the  algorithms 
in  l lie  place  system,  and  1 discovered  that  I had  erred  in  lhc  implementation  of  the 
NewConiposilion  and  that  Alldisjointp  was  required  as  described  earlier. 
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4.  A Slice  of  the  IMP  Code 


While  the  whole  of  the  IMP  code  was  considered  in  formulating  the  theory  and 
building  the  system,  only  a small  slice  of  the  code  was  examined  in  detail.  This  code  is 
central  to  the  operation  of  the  IMP  and  posed  a large  number  of  theoretical  problems. 
Solving  these  problems  took  us  much  further  than  I anticipated.  While  1 have  not 
pushed  any  other  sections  of  the  code  through  the  system,  1 believe  that  the  existing 
theory  and  system  are  sufficient  to  support  proof  of  much  of  the  rest  of  the  code. 

This  chapter  covers  just  the  slice  of  code,  including  a description  of  the  hardware 
and  an  overview  of  the  ARPANET.  In  chapter  five,  we  will  return  to  this  code  and 
show  its  complete  proof  through  the  system. 


4.1  The  ARPANET 


The  ARPANET  is  a communication  system  which  connects  a number  of  "host" 
computers.  These  host  computers  send  messages  to  each  other  through  the  ARPANET. 
The  ARPANET  is  implemented  as  a connected  set  of  IMPs  and  telephone  lines.  The 
IMPs  are  small  computers,  predominantly  Honeywell  316s,  located  next  to  the  various 
hosts.  Each  host  is  connected  to  a single  IMP,  but  one  IMP  may  be  connected  to  more 
than  one  host.  The  IMPs  are  connected  to  each  other  through  leased,  non-switched 
telephone  lines,  usually  capable  of  carrying  60  kilobits  per  second. 

Hosts  send  messages  to  other  hosts  by  transmitting  each  message  to  its  local  IMP. 
Messages  are  limited  to  about  8000  bits  and  begin  with  a leader  which  Includes  the 
address  of  the  destination  host. 

The  sole  role  of  the  IMPs  is  to  move  messages  between  hosts.  To  accomplish  this, 
messages  are  broken  into  smaller  units,  called  packets,  and  the  packets  are  sent  from 
IMP  to  IMP  until  reaching  the  IMP  connected  to  the  destination  host.  Packets  are  no 
longer  than  about  1000  bits.  Messages  are  subdivided  into  packets  solely  for  efficiency 
reasons  which  are  not  relevant  to  the  present  discussion. 

The  program  within  the  IMP  consists  of  several  interrupt-driven  processes. 
When  a packet  arrives  from  another  IMP  or  a message  arrives  from  a host,  the  modem- 
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to-IMP  process  or  the  Host-to-IMP  process  is  started  to  read  the  packet  or  message. 
Messages  are  broken  into  packets  as  they  are  read  in,  so  we  may  view  the  input  from 
the  host  as  just  a sequence  of  numbered  packets. 

Space  for  packets  is  allocated  dynamically  as  needed.  There  is  a fixed  number  of 
packet  buffers,  each  capable  of  holding  exactly  one  packet.  Packet  buffers  are  attached 
to  various  queues  using  standard  list  processing  techniques  A packet  remains  in  the 
packet  buffer  it  was  read  into  until  it  is  transmitted  out  to  another  IMP  or  a host; 
packets  are  never  copied  from  one  place  in  core  to  another. 

There  is  a fixed  number  of  queues  in  the  program:  one  for  each  output  port,  one 
for  packets  waiting  for  routing,  the  free  packetbuffer  queue.  Every  packetbuffer  is  on 
just  one  of  these  queues  or  is  serving  as  an  input  buffer  for  one  of  the  input  ports. 
Collectively,  the  queues  and  the  input  buffers  always  account  for  all  of  the  buffers  in 
the  system.  The  complete  set  of  buffers  is  determined  at  assembly  time. 


4.2  The  31G 


The  Honeywell  316  is  a one  address,  16-bit  minicomputer.  In  the  standard 
configuration,  the  memory  may  have  I6K  words  of  16  bits,  thus  requiring  14  bits  to 
address  each  word. 


The  CPU  has  a single  general  purpose  register  (A)  and  a program  counter  (PC). 
Word  zero  of  memory  acts  as  the  index  register. 

All  instructions  are  one  word  long,  and  have  one  of  two  formats.  Instructions 
which  reference  memory  have  the  following  format  (bit  0 is  the  least  significant  bit): 


flit  lb 
Bit  1 A 
Bits  13-10 
Bit  3 
Bits  8-0 


Indirect  addressing  flag 
Indexing  flag 

Operation  code  (not  equal  to  zero) 
Page  flag 
Address  field 


P.ecause  only  nine  bits  are  provided  in  the  address  field,  an  Instruction  cannot 
address  all  of  memory  directly  If  the  page  flag  is  zero,  the  addi ess  field  holds  an 
absolute  address  and  thus  refers  to  a cell  in  the  first  512  words  of  memory. 

If  the  page  flag  is  one,  the  address  field  holds  a local  address  and  thus  refers  to  a 
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cell  in  the  same  512  word  page  as  the  instruction,  i.e.,  the  high-order  5 bits  are  the  same 
as  the  location  of  the  instruction. 

If  the  index  flag  is  set,  the  contents  of  cell  zero  is  added  to  the  direct  address 
calculated  above. 

If  the  indirect  flag  is  set.  the  address  is  used  as  the  location  of  another  address. 
In  the  new  address  word,  bit  15  is  again  the  indirect  flag,  bit  14  is  the  index  flag  and 
bits  13-0  are  a full  M bit  direct  address,  indirect  addressing  continues  until  an  address 
word  is  encountered  with  the  indirect  flag  set  to  zero.  Indexing  is  applied  at  every  step 
if  the  index  flag  is  on. 

Instructions  which  do  not  reference  memory  are  no-address  instructions.  Bits  13- 
10  of  these  instructions  are  zero  and  the  other  bits  form  an  extended  operation  code. 

The  specific  instructions  of  concern  are  the  following: 


4.2.1  No-address  instructions 

Clear  A register  (CHA);  140040Q 

The  effect  of  this  instruction  is  to  set  all  sixteen  bits  of  the  A register  to  zero. 

Skip  Not  Zero  (SNZ);  1010400 

This  instruction  tests  the  A register.  If  any  of  the  bits  are  1,  the  next  instruction  is 
skipped  If  the  A register  holds  zero,  the  next  instruction  is  executed. 

4.2.2  Memory  referencing  instructions 

Jump  (JflP) ; opcode  * 1 

This  instruction  transfers  control  to  the  effective  address. 

Store  A register  (S T A ) ; opcode  *=  A 

The  contents  of  the  A register  are  copied  into  the  referenced  memory  location. 
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Increment  anc)  ckip  < i RS ) ; opcode  *=  10Q 

The  value  in  the  referenced  memory  location  is  increased  by  1 (modulo  2^).  If 
the  result  is  zero,  the  next  instruction  is  skipped. 

Interchange  Memory  and  A register  (IMA);  opcode  - 1 1 □ 

This  instruction  exchanges  the  contents  of  the  A register  with  contents  of  the  cell 
referenced  in  memory. 


4.3  C.FREE 


We  now  come  to  a specific  section  of  code,  GFREE.  GFREE  is  called  by  an  input 
process  to  allocate  a buffer  from  the  free  packet  buffer  queue  Two  returns  are  possible, 
one  indicating  success  and  the  other  indicating  that  no  free  buffers  existed. 


Location 

Contents 

L abel 

Source  Code 

Comments 

010511 

GFREET: 

BSS  1 

/LAS!  BUFFER  USED 

010512 

000000 

GFREE: 

0 

/GET  A FREF  BUFFER 

010G13 

140040 

C'RA 

010514 

1 2G277 

IMA  FREE  I 

/CLEAR  CHAIN  PTR 

0J0G15 

101040 

SNZ 

01 051 G 

103512 

JMP  GFREF  I 

/NO  BUFFERS,  NO  SKIP 

010517 

024500 

IRS  NFS 

/KFEP  COUNT 

010520 

02G277 

IMA  FREF 

/UPDATE  TREE  LIST 

010521 

011511 

SI  A GFREF.T 

/LFAVE  A CLUE 

010522 

075512 

IRS  GFREE 

/SKIP^SUCCESS 

010523 

103512 

JMP  GFREF  I 

Entry  is  via  a subroutine  call  instruction  which  leaves  its  return  address  in  GFREE 
and  transfers  control  to  the  cell  after  GFREF,  10G13Q.  If  no  buffers  are  available,  the 
return  docs  not  skip  If  successful,  the  return  skips  one  instruction  and  the  A register 
contains  a pointer  to  the  allocated  buffer. 

The  free  list  consists  of  packetbuffers  whose  first  words  arc  strung  together  in  a 
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pointer  chain.  The  last  packet  buffer  header  points  to  a word  which  contains  0.  (This 
is  not  the  same  as  having  the  last  element  point  to  0.)  FREE  points  tc  the  first  packet 
buffer  if  there  is  one,  or  to  the  dummy  packet  buffer  if  the  list  is  empty.  No  packet 
buffer  begins  at  word  0. 

Nf  A and  NFS  contain  counters.  NFA  is  incremented  whenever  a packet  is  put  onto 
the  free  list,  and  Nf  S is  incremented  whenever  a packet  is  taken  off.  The  difference 
between  the  contents  of  NFA  and  NFS  gives  the  actual  number  of  packets  on  the  free  list 
at  any  time,  except  in  the  middle  of  routines  which  change  them. 

As  a convenience  to  one  of  the  callers  of  GFREE,  GFREET  also  contains  a pointer 
to  the  allocated  buffer  if  successful. 

It  is  intended  that  NFS  never  be  incremented  up  to  0 (thus  causing  the  second  1I1A 
to  be  skipped).  The  mechanism  for  preventing  this  is  a background  program  which 
periodically  stores  the  difference  between  the  contents  of  NFA  and  NFS  in  NFA,  and  sets 
NFS  to  0.  This  routine  inhibits  interrupts  when  it  does  this  Correct  operation  of  this 
routine  is  thus  timing-dependent.  We  will  avoid  this  problem  by  explicitly  assuming 
that  the  contents  of  NFS  be  less  than  17/777Q  when  GFREE  is  entered. 

The  places  which  can  be  modified  are  PC,  A,  GFREE,  GFREET,  NFS,  FREE, 
ZFRO  and  the  first  word  of  the  first  packetbuffer.  There  are  also  internal  registers 
which  are  modified.  If  wc  let  Q stand  for  the  internal  registers  and  X stand  for  the 
whole  packetbuffer  list  which  begins  at  FREE,  we  can  say  that  nothing  outside  of  the  list 
Q,  PC,  A,  GFREF,  GFREET,  FREE,  ZERO  and  X is  modified. 

The  final  IRS  must  not  skip.  It  could  only  skip  if  the  calling  location  were 
17/776Q,  so  that  177777Q  would  be  stored  into  GFREE  upon  entry  Addresses  in  this 
range  would  require  a 6TK  address  space  - far  more  than  the  machine  has. 
Consequently,  the  final  IRS  cannot  skip  if  GFREE  actually  holds  a legal  address. 


4.4  Specification  of  GFRF.F. 


before  we  can  contemplate  proving  the  correctness  of  GFREE,  we  need  a dear 
statement  of  the  intended  effect  of  GFREE.  One  straightforward  way  to  write  down  the 
intended  effect  is  to  compare  the  state  of  the  machine  before  GFREE  is  entered  with  the 
state  after  it  has  been  executed. 

T he  conditions  that  are  assumed  to  hold  before  GFREE  is  entered  are  the 
following: 


F>i.  The  program  counter  holds  10S13Q, 

B?.  GFREF  holds  a return  address  ra,  and  ra  is  strictly  less  than  37777Q; 

B3.  The  code  listed  above  has  not  be  i modified; 

BT  The  free  packetbuffer  list  is  well-formed,  a concept  we  will  expand  below, 

B5  NF  S holds  a value  nf  s which  is  strictly  less  than  17777Q 

The  conditions  that  are  assumed  to  hold  after  GFREE  has  been  executed 
depending  upon  whether  there  were  any  packetbuffers  available  on  the  free 
packetbuffer  list.  If  there  were  not,  the  following  conditions  are  expected; 

AZ.  I.  The  program  counter  holds  ra; 

A Z.Z.  The  code  listed  above  has  not  been  modified; 

AZ.3.  The  free  packetbuffer  list  is  still  well-formed  but  empty; 

AZ.T  NFS  still  holds  nfs; 

AZ.fi  Only  the  places  listed  in  item  7 above  may  have  been  modified.  1 his  restriction 
is  one-sided.  It  means  places  not  listed  have  not  been  modified.  It  does  not 
gi  arantcc  that  listed  places  wete  modified. 

If  there  was  a packetbuffer  available,  we  expect  the  following  conditions  to  hold; 
AN  I T he  program  counter  holds  ra-il; 

ANZ.  The  code  listed  above  has  not  been  modified, 

AN3.  The  free  packetbuffer  list  is  still  well-formed  and  accounts  for  all  but  one  of  the 
packetbuffers  in  the  original  list; 

ANT  The  A register  and  GFHEET  hold  a pointer  to  the  other  packetbuffer; 

AN5.  NFS  holds  nf di  1. 

AN6  Only  places  listed  in  item  7 may  have  bern  modified 

Packctbuf fers  are  packet  length  words  long  and  the  entire  set  of  possible 


packetbuffers  is  determined  at  assembly  time.  Buffer-space  is  the  name  of  that  set. 
None  of  the  packetbuffers  begin  at  word  zero  in  memory.  Buffer-space  is  separate 
from  the  code,  NFS,  GFREE,  GFREET,  NFS,  FREE  and  ZERO. 

A packetbuf fer  list  is  a finite  sequence  of  packetbuffers  with  the  first  word  of  all 
but  the  last  packetbuffer  holding  the  address  of  the  first  word  of  the  next  packetbuffer 
and  the  last  packetbuffer  holding  a pointer  to  a word  which  contains  0.  By  convention, 
this  word  is  the  cell  ZERO. 

A slightly  more  precise  way  to  characterize  packetbuffer  lists  is  the  following:  X is 
a packetbuffer  list  beginning  at  y if  X is  a zero-length  sequence  and  y is  the  address  of 
ZERO  or  X is  a sequence  whose  length  is  not  zero,  the  first  element  of  X is  a packetbuffer, 
y is  the  address  of  the  first  word  of  that  packetbuffer  and  the  rest  of  X is  a packetbuffer 
list  beginning  at  the  address  contained  in  the  first  word  in  the  first  packet  buffer  in  X. 
The  list  of  free  packetbuffers  is  the  packetbuffer  list  beginning  at  the  address  contained 
in  FREE. 


4.5  Informal  proof  of  the  correctness  of  GFREE 


We  arc  now  ready  to  look  at  the  reasons  why  wc  believe  GFREE  performs  correctly. 
Our  goal  is  to  show  that  if  the  initial  conditions  Bl  through  B5  are  true  at  some  time, 
then  execution  of  GFREE  leads  to  either  AZI  through  AZ5  or  AN1  through  AN6.  Our 
technique  for  achieving  this  goal  is  to  display  the  state  of  the  machine,  and  then  step 
through  the  program  updating  the  display.  This  technique  is  generally  called  symbolic 
execution.21 

We  clearly  need  to  display  current  values  for  the  program  counter  (PC) , A, 
GFREE,  GFREET,  NFS,  FRFE  and  the  free  packetbuffer  list.  The  free  packetbuffer  list 
piesents  a problem  because  wc  don’t  know  exactly  what  words  in  memory  are  involved. 
However,  we  can  divide  the  analysis  into  two  cases,  one  for  an  empty  list  and  one  for  a 
non-empty  list.  In  both  cases  the  iist  is  represented  symbolically  by  X. 

One  other  detail  needs  attention.  For  a careful  symbolic  execution,  we  need  to 
assure  ourseives  that  the  indirect  addressing  computed  at  10G14Q,  1051GQ  and  10523Q 
all  refer  to  cells  containing  numbers  strictly  less  thin  100000Q,  i.e.,  that  the  indirect 


21 


See,  for  example,  "Symbolic  Execution  ami  Testing,"  by  James  King,  IBM  Research 


report,  RC  f>0fl2. 


addressing  terminates  in  just  one  subcycle.  To  follow  this  detail,  we’ll  make  use  of  a 
fictitious  microprogram  counter  (UPC)  and  an  internal  memory  address  register  (M). 
The  UPC  holds  either  top,  adclr  or  action.  When  UPC  holds  top,  the  contents  of  PC  is 
the  address  of  the  next  instruction.  If  the  instruction  is  a memory  referencing 
instruction,  UPC  is  set  to  addr  and  address  fetches  take  place  until  a word  is  accessed 
with  the  indirect  bit  off.  At  that  point,  the  UPC  is  set  to  act  ion  and  the  instruction  is 
executed. 

l or  no-address  instructions,  execution  takes  place  immediately  and  the  UPC  retains 
the  value  top 

Here  is  the  display  for  the  initial  state.  The  numbers  above  the  symbols  are  the 
memory  address.  In  the  case  of  the  free  packetbuffer  list,  p is  the  address  of  the  first 


word  of  the  first  buffer. 
Memory  cell 

5000 

10S12Q 

1051  IQ 

277Q 

P 

Name  UPC  PC 

M A 

NFS 

CFREE 

GFREET 

FREE 

X 

Value  top  10513Q 

? ? 

nf  s 

ra 

? 

P 

We  now  begin  execution.  T he  instruction  at  10513Q  is  CRA,  so 

only  PC  and 

A are 

changed. 

Memory  cell 

500Q 

10S12Q 

1051  IQ 

2770 

P 

Name  UPC  PC 

M h 

NFS 

GF  REF 

GFREET 

FREE 

X 

Value  top  1051AQ 

? 0 

nf  s 

ra 

? 

P 

The  PC  now  points  to  an  IMA  instruction.  Before  proceeding,  we  need  to  know 
whether  the  fiee  packetbuffer  list  is  empty.  We  consider  the  empty  case  first. 
Accordingly,  the  state  we  are  considering  is  thus 


Memory 

ce  1 1 

5000 

10512Q 

1051  IQ 

277Q 

P 

Name 

UPC 

PC 

M 

A 

NFS 

GFREE 

GFREET 

FREE 

ZERO 

Va  1 ue 

top 

1051AQ 

? 

0 

nf  5 

ra 

? 

y 

0 

The  IMA  instruction  is  now  partially  decoded  and  discovered  to  be  a memory 
reference  instruction,  leading  to 


Memory 

ce  1 ! 

5000 

105120 

1 051 1 Q 

277Q 

P 

Name 

UPC  PC 

M 

A 

NFS 

GF  RFF 

GFREFT 

FREE 

ZERO 

Va  1 ue 

addr  1051AQ 

277Q 

0 

nf  s 

r a 

? 

P 

0 

277Q  is  the  indirect  address. 

An  indirect  addiessing  cycle  is  taken,  leading  to 

Memory 

ce  1 1 

5000 

10512Q 

1 051 1 Q 

277Q 

P 

Name 

UPC  PC 

M 

A 

NFS 

GFREE 

GFREET 

FREE 

ZERO 

Va  1 ue 

action  10514Q 

P 

0 

nf  c 

ra 

? 

P 

0 

The  operation  code  is  now  examined  and  seen  to  be  1 1 □ indicating  an  IMA 
instruction.  The  contents  of  cell  277Q  is  p,  and  the  contents  of  A is  0. 

Hy  convention,  p is  the  address  of  ZERO,  a cell  holding  0.  After  execution  of  the 


IMA  instruction,  the  state  is: 

Memory  ce 1 1 

500Q 

10512Q 

10511Q 

277Q 

P 

Name  UPC 

PC 

M 

A 

NFS 

CFREE 

GFREET 

FREE 

ZERO 

Value  top 

1051SQ 

? 

0 

nf  s 

ra 

P 

0 

Interpretation  of  the 

instruction 

at  10S1SQ  now  takes  place. 

This  is 

a SNZ 

instruction,  which  does  not  skip. 

The  new  state  is. 

Memory  ce 1 1 

S00Q 

10512Q 

10511Q 

277Q 

P 

Name  UPC 

PC 

M 

A 

NFS 

GFREE 

GFREET 

FREE 

ZERO 

Value  top 

1051SQ 

? 

0 

nf  s 

ra 

? 

P 

0 

The  instruction  at  10516Q 

is  an 

indirect 

jump.  After  the  fetch 

of  the 

indirect 

address,  the  state 
Memory  ce 1 1 

is: 

B00Q 

10S12Q 

10S11Q 

2770 

P 

Name  Uf'C 

PC 

M 

A 

NFS 

GFREE 

GFREET 

FREE 

ZERO 

Value  addr 

1051 70 

ra 

0 

nf  s 

ra 

? 

P 

0 

Since  ra  is  an  address,  the  high-order  bit  of  M is  off  and  no 

further 

indirect 

addressing  takes  place.  After  the 

jump, 

the  state  becomes: 

Memory  ce 1 1 

500Q 

J0S12Q 

10S11Q 

277Q 

P 

Name  UPC 

PC 

M 

A 

NFS 

GFREE 

GFREET 

FREE 

ZERO 

Value  top 

ra 

0 

nf  s 

ra 

? 

P 

0 

This  Is  a final  state. 

Alternatively,  the  free  list  might  not  have  been  empty. 

We  return 

to  the  state  just 

prior  to  execution  of  the  IMA  instruction  and  the 

state  we  are  considering  is:  24 

Memory  cell 

B00Q 

1051 20 

1 051 1 Q 

277Q 

P 

Name  UPC 

PC 

M 

A 

NFS 

GFREF 

GFREET 

FREE 

X 

Value  top 

10514Q 

? 

0 

nf  s 

ra 

? 

P 

Pl 

Again  we 

complete  the  indirect 

address 

and  the  state  just  prior  to  the  actual 

exchange  is: 
Memory  cell 

B00Q 

105120 

1051 IQ 

277Q 

P 

Name  UPC 

PC 

M 

A 

NFS 

GFREE 

GFREET 

FREE 

X 

24  In  ihr 

displays  which 

follow, 

X refers  to  just  th 

e first  word  of  the  first 

p;ickcthuffor  instead  of  the  whole  packclbuffcr  list. 


Value  action  10S1SQ  p 


0 


P 


Pi 


n f s r a 


Note  that  we  needed  to  know  that  the  high-order  bit  in  FREE  was  zero  in  order  to 
terminate  the  indirect  addressing  cycle.  After  execution  of  the  exchange,  the  new  state 
is 


Memory 

ce  1 1 

&00Q 

10B12Q 

1 051 IQ 

277Q 

P 

Nome 

UPC 

PC 

M 

A 

NFS 

GFREE 

GFREET 

FREE 

X 

Va  1 ue 

top 

10S15Q 

? 

Pi 

nf  s 

ra 

? 

P 

0 

The  A register  now 

holds 

Pi* 

pi  cannot 

be  zero, 

so  the  SNZ 

instruction  at 

10G15Q  will  ski 

p After  its  execution,  we  have: 

Memory  ce  1 1 

S00Q 

10512Q 

10S11Q 

277Q 

P 

Name 

UPC 

PC 

M 

A 

NFS 

GFREE 

GFREET 

FREE 

X 

Va  1 ue 

top 

10517Q 

? 

Pi 

nf  s 

ra 

? 

P 

0 

The  IRS 

instruction 

at  10S17Q  is 

now  executed,  nfs 

is  small  eno 

ugh  to 

prevent 

overflow 

, so  we 

arrive  at. 

Memory 

ce  1 1 

500Q 

10512Q 

10B11Q 

2770 

P 

Name 

UPC 

PC 

M 

A 

NFS 

GFREE 

GFREET 

FREE 

X 

Va  1 ue 

top 

10B20Q 

? 

Pi 

nf  5+1 

ra 

? 

P 

0 

The  instruction  at  10520Q  is  the  second  IMA  instruction.  It  just  causes  the 
contents  of  A and  FREE  to  be  interchanged. 


Memory  ce 1 1 

S00Q 

10B12Q 

1051  IQ 

277Q 

P 

Name  UPC 

PC 

M 

A 

NFS 

GFREE 

GFREET 

FREE 

X 

Value  top 

10S21Q 

? 

P 

nf  s+l 

ra 

? 

Pi 

0 

The  next  three  instructions  are  quite  straightforward  p is  put  into  GFREET,  the 
return  address  is  incremented  by  I and  the  routine  is  exited.  The  fact  that  ra  is  a less 
than  3777/Q  is  needed  three  times,  once  to  show  that  the  IRS  doesn’t  skip,  once  to  show 
that  the  indirect  addressing  cycle  for  the  jump  terminates,  and  once  to  show  that  ra+1 
fits  into  the  low  order  14  bits  of  PC.  The  final  state  is: 


Memory  ce 1 1 

500Q 

10S12Q 

10B11Q 

277Q 

P 

Name  UPC 

PC 

M 

A 

NFS 

GFREE 

GFREET 

FREE 

X 

Value  top 

rail 

? 

P 

nf  54 1 

rar  1 

P 

Pi 

0 

In  the  state  displays  above,  each  column  is  dedicated  to  a specific  memory  cell  or 
register,  and  it  naturally  assumed  that  each  of  these  cells  or  registers  is  completely 
disjoint  from  all  of  the  others.  As  we  updated  one  column  in  the  display,  we  made  the 
strong  assumption  that  each  of  the  other  columns  remained  valid. 

For  the  registers  and  fixed  memory  locations,  the  independence  of  each  place  from 


all  other  places  is  easy  to  see  and  doesn’t  change  during  execution.  For  variable  places 
like  the  free  packet  buffer  list,  however,  we  need  some  assurance  that  X is  disjoint  from 
all  of  the  other  places. 

T he  general  situation  can  be  quite  complicated.  Indirect  addressing  and  list- 
structured  data  provide  many  possibilities  for  implicit  sharing  of  structures,  in  order  to 
update  the  state  description  correctly,  all  possible  dependencies  among  the  places  must 
be  known. 

In  practice,  sharing  of  places  is  carefully  controlled  by  the  programmer  and  the 
number  of  possible  intersections  is  small.  In  the  IMP  code,  memory  is  divided  into 
disjoint  regions  containing  code,  fixed  data  areas  and  variable  data  areas.  The  primary 
use  of  the  variable  data  area  is  for  packet  buffers.  T hese  regions  are  determined  at 
assembly  time  and  remain  fixed  for  the  life  of  the  (particular  version  of  the)  IMP  code. 
The  variable  data  area  is  further  divided  into  packet  buffer  space  and  other  allocatable 
storage.  The  packet  buffer  space  in  turn  is  further  structured  into  individual  packet 
buffers.  While  we  didn't  say  exactly  what  cell  in  memory  was  named  ZERO,  we  need  to 
know  that  ZERO  is  within  the  fixed  data  area  and  hence  is  not  within  the  variable  data 
area.  Moreover,  ZERO  is  disjoint  from  NFS,  FREE,  GFREE,  GFREET,  etc.  Similarly,  we 
need  to  know  that  p is  the  address  of  the  first  word  of  a packet  buffer,  and  hence 
cannot  be  the  address  of  any  cell  in  the  fixed  data  region  or  the  code  region,  pj  is  also 
constrained:  it  may  be  either  an  address  of  the  first  word  of  a packet  buffer  or  it  may  be 
the  address  of  ZERO,  but  nothing  else. 

The  assurance  that  these  variable  addresses  are  disjoint  from  particular  other 
addresses  allows  us  to  represent  the  state  of  the  machine  as  a set  of  independent  places, 
each  holding  its  own  value,  and  to  update  the  contents  of  each  place  independently  of 
the  others.  When  this  assurance  is  lacking  and  the  contents  of  a place  are  modified,  the 
contents  of  all  other  places  which  are  not  known  to  be  disjoint  may  have  been  changed. 
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5.  Proof  of  GFKEE 


In  this  chapter  we  examine  a trace  of  the  proofchecker  processing  the  proof  of 
GI  RF.E.  T he  input  to  the  proofchecker  is  a series  of  commands;  all  of  these  are 
included  in  the  trace  output.  At  various  points,  the  trace  also  includes  a list  of  the 
predicates  added  to  or  deleted  from  the  current  context  or,  in  the  case  of  an  Open 
command,  the  predicates  copied  into  the  new  context  from  a superior  context.  The 
listing  of  these  predicates  is  controlled  by  switches  and  the  points  at  which  these 
switches  are  turned  on  and  off  is  noted  in  the  text.  Each  command  which  is  input  to 
the  system  is  noted  by  a preceding  bullet  (•). 

Most  of  the  commands  require  a reference  to  an  existing  predicate  within  the 
current  context,  and  I have  chosen  to  use  the  Interlisp  pattern-matching  capability  to 
implement  this  requirement  When  a command  contains  a pattern,  the  pattern  is 
matched  against  each  of  the  predicates  accessible  in  the  current  context  until  a match  is 
found  Predicates  are  searched  in  LIFO  order,  the  most  recently  created  predicate  is 
checked  first.  If  no  predicate  is  found  which  matches  the  pattern,  the  command  fails. 

Internally,  predicates  are  stored  in  prefix  format.  If  the  predicate 
•HE H- (.PC) -14004 0Q  is  entered  into  the  system,  it  is  stored  as 

(IQ  (COT  (SL'L  MEM  (DOT  PC)))  140040Q) 

For  the  convenience  of  the  user,  patterns  may  be  written  as  if  they  were  to  match  the 
external  syntax  of  the  predicates.  Before  the  matching  process  takes  place,  a pattern  is 
also  transformed  to  an  internal  prefix  format.  For  example,  the  pattern  &-140040Q  may 
be  used  to  select  the  predicate  above  because  this  pattern  will  be  transformed  into  (EQ  & 
140040Q)  before  the  match  is  attempted.  ("8"  means  "match  any  single  element  of  a 
list")  For  full  details  on  the  pattern  matching  capability,  sec  section  23  of  the  Interlisp 
manual.^’  The  use  of  the  pattern  matcher  was  a convenient,  short-term  expediency,  and 
is  likely  to  be  changed  in  future  implementations.  Some  of  the  problems  encountered  in 
using  this  scheme  are  discussed  in  the  next  chapter 


Warren  Tcileirnan,  Intcrlisp  Reference  Manual,  Xerox  Palo  Alto  Research  Center, 
Alto,  California,  1975. 
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5.1  Proof  plan 


The  basic  proof  of  GFREE  consists  of  four  sections.  The  first  section  steps  the 
machine  through  the  first  instruction,  CRA.  The  second  section  steps  the  machine 
through  the  next  two  instructions  under  the  assumption  that  the  free  buffer  list  is 
empty.  The  third  section  steps  the  machine  through  the  second,  fourth  and  following 
instructions  under  the  assumption  that  the  free  list  is  not  empty.  The  final  section 
combines  the  results  of  previous  two  sections  to  re-execute  the  body  of  GFREE  and 
reach  an  exit  condition.  This  plan  is  summarized  in  the  following  outline. 


Begin  proof  of  GFREE 

section  Is  execution  of  first  instruction 
Begin  proof  of  GFREE  assuming  list  is  empty 

section  2:  execution  of  2nd  and  3rd  instructions 
end  of  proof  of  empty  case 
Begin  proof  of  GFREE  assuming  list  is  not  empty 
section  3:  execution  of  other  instructions 
end  of  proof  of  non-empty  case 

section  4:  single  step  execution  of  SU  resulting  from  combination 
of  SDs  generated  by  prior  subproofs 
end  of  proof  of  GFREE 

Before  starting  the  proof  of  GFREE,  it  is  necessary  to  enter  into  the  system  a listing  of 
the  code  for  GFREE,  a list  of  notations  used  in  the  description  of  GFREE,  a description 
of  the  316  itself,  and  a few  facts  about  the  world  that  the  proof  system  does  not  have 
built  in.  These  add  several  steps  to  the  outline  of  the  proof.  To  enter  all  of  the 
required  information,  we  pretend  that  we  are  starting  a proof  and  enter  the  required 
information  as  preconditions.  No  postconditions  will  be  supplied  and  the  proofs  will 
never  be  closed.  The  specification  and  proof  of  GFREE  therefore  take  place  within 
several  hypotheses  and  are  usable  only  under  the  same  hypotheses. 


Begin  "proof"  introducing  general  facts  about  the  world 
Begin  "proof"  introducing  description  of  the  31G 

Begin  "proof"  introducing  listing  of  the  code  for  GFREE 
Begin  "proof"  introducing  notation  used  in 
specification  of  GFREE 
Begin  real  proof  of  GFREE 
section  1 

Begin  proof  of  empty  case 
section  2 


>nd  of  proof  of  empty  case 
Begin  proof  of  nonempty  case 
sc  • t i on  3 

end  of  proof  of  nonempty  case 
sect  ion  4 

end  of  p'oof  of  GFREE 

The  above  outline  is  complete  except  for  one  detail.  GFREE  is  specified  in  terms  of  a 
SD  that  has  another  SD  in  \ s postcondition!  In  other  words,  the  state  delta  that 
describes  the  operation  of  GFRE  has  the  following  form. 

(SD  (pre:  , . . ) 

(mod:  . . . ) 

(env:  . . . ) 

(post : ...  (SD  (pre:  . . . ) 

(mod:  ...) 

(env:  ...) 

(post:  ...) 

(vars:  ...)) 

(vars:  . . . ) ) 

The  reasons  for  specifying  GFREE  in  this  fori  t are  discussed  below.  As  a consequence, 
however,  an  additional  level  of  proof  has  to  be  included  in  our  outline.  The  following 
is  the  total  outline. 

Begin  "proof"  introducing  general  facts  about  the  world 
Begin  "proof"  introducing  description  ol  the  316 

Begin  "proof"  introducing  listing  of  the  code  for  GFREE 
Begin  "proof"  introducing  notation  used  in 
specification  of  GFREE 
Begin  real  proof  of  GFREE  --  outer  1 ayer 
Begin  proof  of  inne^  layer  of  GFi'EF. 
section  1 

Begin  proof  of  empty. case 
section  2 

end  of  proof  of  empty  case 
Begin  proof  of  nonempty  case 
sect  ion  3 

end  of  proof  of  nonempty  case 
sect i on  4 

end  of  proof  of  inner  layer  of  GFREE 
end  of  proof  of  outer  layer  of  GFREE 


5.2  General  facts 


The  first  command  establishes  the  top  level  context  by  postulating  some  general 
theorems  that  arc  not  built  into  the  simplification  routines  but  are  necessary  at  a later 
point  in  the  proof.  In  a mature  system,  there  would  be  a large  number  of  these  general 
facts  that  would  be  available  and  the  proof  system  would  be  started  wi'h  these  already 
present.  Although  these  are  written  as  SDs,  the  pre-  and  postconditions  make  no 
reference  to  a machine  state  and  the  environment  and  modification  lists  are  empty. 
Under  these  conditions,  a SD  is  exactly  equivalent  to  a (universally  quantified) 
conditional  statement.  Correspondingly,  instantiation  and  application  of  these  SDs  is 
equivalent  to  instantiating  the  equivalent  quantified  conditional  statement  and  then 
using  the  modus  ponens  inference  rule.  Since  the  machinery  to  manipulate  SDs  already 
existed,  we  did  not  bother  to  build  the  machinery  to  handle  simple  conditional 
statements 


The  five  general  facts  which  are  supplied  state  that  a list  is  equal  to  the  concatenation 
of  its  first  element  with  the  rest  of  it,  that  this  same  concatenation  yields  a permutation 
of  the  original  list  (because  it  is  in  fact  identical!),  that  a number  is  either  zero  or  not 
zero,  that  adding  1 to  both  sides  of  an  inequality  preserves  the  inequality,  and  that 
positive  numbers  are  not  zero  e is  the  infix  operator  for  concatenation;  its  prefix  form 
is  catenate.  The  prefix  form  for  is  a permutat  ion  of  is  Permutat  i onp.  Although 
the  syntax  for  these  operators  is  predefined,  no  semantics  are  built  into  the  system  at  all. 


• (Open  (pre: 


(SO  (pro:) 

(mod: ) 

I'cnv: ) 

(post:  x^<x°8>0x,l) 

(vars:  x ) > 

(SO  (pre:  x-<xo0>@x,l) 

(mod: 1 
(env: ) 

(post:  (x  is  a permutation  of  <x°0>ex,l)) 
(vars:  x) ) 

(SO  (pre: ) 

(mod: ) 

(env:  ) 

(post:  (a=0  or  a*0)) 

(vars:  a)) 

(SO  (pro:  (x  is  less  than  y) ) 

(mod: ) 

(env: ) 

(post:  (x-tl  is  less  than  y + 1 ) ) 
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(vars:  x y)) 

(SP  (prc:  (0  is  less  than  x)) 
(mod: ) 

(env: ) 

(post:  x*0) 

(vars:  x))) 

(mod: ) 

(env: ) 

(post : ) 

(vars: ) ) 


5.3  Definition  of  tlie  316 


The  following  Open  command  establishes  a subordinate  context  in  which  a small  subset 
of  the  Honeywell  316  hardware  is  defined.  The  SDs  that  are  introduced  are  identical  to 
the  set  displayed  in  chapter  two  After  the  SDs  come  two  declarations  about  places  in 
the  machine.  The  first  declaration  introduces  the  microprogram  counter  UPC,  the 
program  counter  PC.  memory  MEM,  internal  registers  M,  I , OP  and  C,  and  the 
accumulator  A.  These  are  completely  disjoint  from  each  other  and  partition  OMEGA. 
OMEGA  represents  all  of  the  space  in  the  n achine,  so  the  effect  of  this  declaration  is  these 
places  are  the  only  places  in  the  machine.  The  second  declaration  subdivides  memory. 
In  principle,  each  of  the  16,381  cells  in  memory  should  be  listed  separately,  but  only  the 
cells  of  interest  are  explicitly  named  here  ZERO  is  a specific  cell  in  memory  that  is 
disjoint  from  all  cf  the  other  cells  listed.  In  a more  complete  treatment,  it  would  be 
introduced  as  an  alternate  name  for  a specifically  enumerated  cell,  this  is  how  the  other 
symbols  in  the  code  for  GFREE  arc  treated  later.  Introducing  ZERO  without  disclosing 
its  address  illustrates  the  power  of  the  place  graph. 

In  a similar  way,  Bufferplace  refers  to  all  of  the  cells  in  memory  that  can  be  used  to 
form  buffers  The  declaration  is  again  silent  about  which  cells  these  are,  but  they  are 
known  to  be  disjoint  from  ZERO  and  the  other  listed  cells. 

Following  the  Open  command  arc  three  commands  to  build  up  the  place  graph.  The 
first  two  just  copy  the  information  provided  by  the  declarations  just  discussed.  The 
third  declaration  introduces  the  name  (J  as  a covering  of  the  internal  registers  of  the 
machine  and  adds  the  covering  to  the  place  graph  In  the  SDs  that  Describe  the  316,  Q 
is  used  in  the  modification  list  when  it  is  desired  to  specify  that  all  of  the  internal  state 
of  the  GPU  may  have  changed  Q used  in  this  context  is  completely  separate  from  the  Q 
used  on  the  end  of  constants  to  indicate  octal  representation. 


. riEho  ( . PC)  =1 A0040Q) 


• (Open  (pre:  (SD  (pres  . UrJC  = top  .PC=pc 
(mod:  Q PC  A) 

(env: ) 

(posts  .UPC=top  . PC=  (pc-v  1 ) ; 1 3 .A=0) 

(varss  pc)) 

(SO  (pres  . UPC = top  .PC=pc  .MEM"  (.PC)  «=101340Q) 

(mods  Q PC) 

(env: ) 

(posts  . UPC=top  (if  . A-0 

then  .PC=  (pc+1 ) ; 13 
else  .PC= (pc+2) ; 13) ) 

(varss  pc)) 

(SO  (pres  . UPC=top  . MEM»  ( . PC) ; 1 3, 10*0) 

(mods  Q) 

(env: ) 

(post:  . 0P=.MEM"  (.PC) ; 13, 10  .UPOaddr  . I =.MEM» ( . PC) °1S 
(if  .MEMo (.PC) =9=0 

then  .M=. MEM" (.PC); 8 

else  . M=.MEMo(.PC) ;8+(L0GAN0  .PC  377000Q) ) ) 

(varss ) ) 

(SO  (pre:  .UPC=addr  .1=0) 

(mcd:  UPC) 

(env: ) 

(post:  ,UPC=act i on) 

(varss ) ) 

(SD  (pre:  .UPC=addr  .1=1  .M=m) 

(mods  UPC  I M) 

(env: ) 

(post:  . UPC=addr  . M= . MLM«m; 1 3 . 1 = .MEM°mul5) 

(varss  m)) 

(SO  (pre:  .UPC=action  .0P=11  .PC=pc  .A=a  . M-m  .MEM»m=b) 
(mod:  Q PC  A MEM°!n) 

(env: ) 

(post:  . UPC=top  .PC=(pc-il);13  .A^b  .MEM»m=a) 

( vars:  pc  « a bit 
(SO  (pre:  ,UPC=action  ,0P=1  .M=m) 

(mod:  Q PC) 

(env: ) 

(post:  . UPC=  top  . PC=m) 

(vars:  m)) 

(SO  (pre:  .UPC=action  .0P=A  -M=m  .PC=pc) 

(mod:  Q PC  MEM»m) 
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(cnv: ) 

(post:  .UPC- top  ,PC- (pcH  1 ) ; 13  .MEM-m-.A) 

(vars:  m pc) ) 

(SO  (prc:  .UPC- act  i on  .OP-10  .M-m  ,MEM-m=v  .PC=pc) 

(mod:  Q PC  MEM»m) 

(cnv: ) 

(post:  .UPC-top  . MEM-m=  (v-t  1) ; 15  (if  .MEM-m=0 

then  . PC- (pc+2) ; 13 
else  .PC=(pc+l) ;13) ) 

(vars:  m pc  v) ) 

(Covering  OMEGA  <UPC  PC  MEM  M I A C 0P>) 

(Covering  MEM 

<MFM-277Q  MEM-500Q  MEM-1051  IQ  MEM-105120 
MEM-105130  MEM-10514Q  MEM-105150  MEM«»10516Q 
MEM-105170  MEM-1 0520Q  MEM-10S21Q  MEM-10522Q 
MEM-10523Q  BufferSpace  ZER0>1) 

(mod:  OMEGA) 

(cnv: ) 

(post: ) 

(vars:  UPC  PC  MEM  M 1 A C OP  Q BufferSpace  ZERO)) 

• (NeuOecompos i t i on  (Covering  OMEGA  <UPC  PC  MEM  M I A C 0P>)) 

• (NeuDecompos i t i on  (Covering  MEM 

<MEM-277Q  MEM-500Q  MEM-1051  IQ  MEM-10512Q 
Mi  M-10513Q  MEM-105140  MEM-10515Q 
MEM-105160  MEM-105170  MEM-105200 
MEM-105210  MEM-105220  MEM-10523Q 
BufferSpace  ZERD>)) 

• (NeuCompos i t i on  (Covering  0 <UPC  M I 0P>)) 


5.4  listing  of  CFR EE 


The  following  Open  command  establishes  a further  subordinate  context  In  which  the 
instructions  which  comprise  GFREE  are  entered  In  addition,  the  symbols  FREE, 
Gf  REE,  GFREFT  and  NFS  are  equated  to  specific  locations  in  memory.  Altogether,  this 
information  corresponds  to  the  output  from  an  assembler. 

After  the  Open  command  comes  a set  of  commands  to  enter  the  symbol  definitions  into 
the  place  graph.  PureCode  is  introduced  as  a name  to  cover  all  of  the  locations 
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containing  code  which  docs  not  change  during  the  operation  of  GFREE  PureCode  will 
be  used  in  the  environment  list  of  the  SD  which  specifies  how  GFREE  operates. 

• (Open  (pre:  . MLM-10513CM 40040Q  .MEM<.10G14a=126277Q 

. M[  H°l  0S  150=101 0400  . HEM °1 0bl 6Q= 1 03&1 2Q  .MEM°10517Q=24S00Q 
.MEM°10b20Q=26277Q  .MEM°10b21Q=1151ia  .MEf1»10522Ch25512Q 
. MEM  °1 0b23Q=l 0351 2Q  .ZERO-0  FREE=t1EM°277Q  GFREE  =nEf1<>l 051 2Q 
G)  REET=MEM«10S11G  NFS=MEM"500Q) 

(mod:  OMEGA) 

(env: ) 

(post : ) 

(vars:  FREE  GFREE  GFREE T NFS  PureCode)) 

• (EnterSynonym  FREE-MEM-277Q) 

• (EnterSynonym  NFS=MEM°500Q) 

• (EnterSynonym  GFREET=MEM-1051 IQ) 

• (EnterSynonym  GFREE-MEM«10512Q) 

• (NewCompos i t i on  (Covering  PureCode 

<MEM-10513Q  MEMol0S14Q  MEt1ol0515Q  MEM°10516Q 
MEMol0517Q  MEM»10S20Q  MEM»10S21Q  MEM-10S22Q 
MEM-10S23Q>)) 


5.5  Additional  notation 


At  this  point,  definitions  for  "x  is  pointing  to  y”,  "x  is  a packet  buffer",  and  "x  is 
bufferlist  beginning  at  y”  are  introduced.  1 he  definitions  involve  extension  to  the 
external  syntax  as  well  as  postulation  of  the  semantic  content  of  the  new  terms.  These 
definitions  are  different  from  the  theorems  contained  in  the  top  level  Open  because  they 
are  applicable  only  to  the  IMP  code.  The  format  used  here  to  introduce  the  syntactic 
extension  is  taken  directly  from  CLISP.2<*  The  semantic  definition  consists  of  a name,  a 
piedicate  which  defines  the  meaning  of  the  name,  and  rule  for  computing  the  support 
of  forms  containing  the  name.  If  the  rule  for  computing  the  support  is  simply  the  union 
of  the  supports  of  the  arguments,  the  rule  need  not  be  specified.  In  principle,  this  rule 
must  be  justified  by  an  analysis  of  the  definition  to  show  that  the  list  of  places 
computed  by  the  rule  at  least  covers  the  set  of  places  containing  values  used  in  the 
predicate  This  requirement  is  not  implemented,  however,  and  the  proofchecker 
contains  a logical  flaw  until  the  support  rule  is  forcefully  checked 


n /* 


£<1 


See  chapter  2.1  of  the  Inlcrlisp  manual. 
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• (Oef ineSyntax  Fointerp  (NEWISUORD  ' (x  is  pointing  to  y) 

' (are  po i nt i ng  to  y) 

' (Pointerp  x y) 

' (x  y))) 

• (Oe f i neOperator  Pointerp  ((SO  (pre:  (x  is  pointing  to  y) ) 

(mod: ) 

(env: ) 

(post:  . x^y/OEN) 

( var s:  x y) ) 
and  (SO  (pre:  . x=y/NE(1) 

(mod: ) 

(env: ) 

(post:  (x  is  pointing  to  y) ) 

(vars:  x y) ) ) 

NIL) 

• (Def ineSyntax  PacketBuf ferp  (NEUISUORD  ' (x  is  a packet  buffer) 

'(are  packet  buffers) 

' (PacketBuf ferp  x) 

' (x) ) ) 

• (De f i neOperator  Packe tBuf f erp 

[(SO  (pre:  (x  is  a packet  buffer)) 

(mod: ) 

(env: ) 

(post:  (FS  (i)  x- MEN, i ; (packet  I ength-1) ) ) 

(vars:  x)) 

and  (SO  (pre:  (TS  (i)  x=f1EM,  i ; (packet  I ength-1 ) ) ) 
(mod: ) 

(env: ) 

(post:  (x  is  a packet  buffer) 

(vars:  x] 

Nil) 

• (Oef ineSyntax  PacketBuf ferl i stp 

(NiUISUORD  ' (x  is  a buffer  list  beginning  at  y' 

'NIL  ' (PacketBuf ferL i stp  x y) 

' (x  y))) 

• (Oe f i neOperator  Packe tBuf ferL i stp 

((SO  (pre:  (x  is  a butferl  ist  beginning  at  y) ) 

(mod: ) 

(env: ) 

(post:  (Subsetp  x BufferSpace) 

IJX0 

(y  is  less  than  37777Q) 
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(if  (LENGTH  x)^0 
then  y^ZERQ/MEM 

else  x °0  is  a packet  buffer  and 

y=xo0o0/HEf1 

and  x,l  is  a buffer  list  beginning 
at  • x °0 °0) ) 

(vars:  x y) ) 

and  (SD  (pre:  (Subsetp  x BufferSpace) 
y*0 

(y  is  less  than  37777Q) 

(if  (LENGTH  x)=0 
then  y=ZER0/MEM 
else  x°0  is  a packet  buffer 
and  y=x°0°0/MEM 
and  x, 1 is  a buf fer I i st 
beginning  at  .xo0o0)) 

(mod: ) 

(env: ) 

(post:  (x  is  a bufferlist  beginning  at  y) ) 
(vars:  x y) ) ) 

<.01  U2>) 


5.6  Specification  of  CFREE 


The  next  Open  command  introduces  the  forma!  specification  of  GFREE.  The 
specification  is  written  as  a compound  SD;  the  postcondition  of  the  top  SD  contains 
another  SD.  The  reason  for  this  circumlocution  is  the  need  to  refer  to  a variable  place 
which  represents  the  list  of  free  buffers.  Whenever  a new  subproof  is  begun,  the  list  of 
places  that  might  be  modified  needs  to  be  known  All  predicates  in  superior  contexts 
which  depend  upon  any  of  these  places  are  detached  from  the  database  and  stored 
safely  away.  ( Those  which  are  also  supported  entirely  within  the  environment  list  are 
then  duplicated  and  added  to  the  new  context ) Since  the  relationship  of  the  free  buffer 
list  to  the  rest  of  memory  is  one  of  the  facts  that  is  listed  in  the  precondition  for 
GFREE,  it  is  necessary  to  delay  using  the  name  of  the  free  buffer  list  until  it  can  be 
entered  into  the  place  graph.  In  the  precondition  of  the  outer  SD,  x is  introduced  as  the 
list  of  free  buffers.  When  the  system  tries  to  compute  the  support  for 
(PacketBuf ferL i stp  x .FREE),  it  finds  that  x is  unregistered  and  defaults  the 
support  to  OMEGA. 
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Prior  to  beginning  the  subproof  corresponding  to  the  inner  SD,  x is  entered  into  the 
place  graph  As  p art  of  the  process  of  entering  a new  name  into  the  place  graph,  the 
system  checks  whether  any  predicates  in  the  current  context  are  supported  by  OtIEGA.  If 
so,  the  support^fo:  these  predicates  are  recomputed  If  the  recomputed  support  cjoes  not 
contain  0(11  GA,  the  predicate  is  removed  from  ONEGA's  list  and  attached  to  the  correct 
places. 

The  inner  SD  contains  the  meat  of  the  specification.  Its  modification  list  contains  x 
along  with  all  the  other  places  that  are  modified.  Since  the  operation  of  CFREE 
depends  strongly  upon  whether  or  not  the  the  free  buffer  list  was  empty  when  GFREE 
was  entered,  the  postcondition  reflects  this  difference  by  appearing  as  a conditional 
statement.  Notice  that  final  values  are  specified  for  ZERO  and  NFS,  even  in  the  cases 
where  these  places  are  not  actually  modified  These  clauses  are  required  because  ZERO 
and  NFS  are  contained  in  the  modification  list  and  are  assumed  by  the  proof  system  to 
be  modified  in  every  execution  of  GFREE  Were  it  desired  to  eliminate  the  listing  of 
.ZERO-0  from  the  non-empty  case  and  the  listing  of  .NFS=nfs  from  the  empty  case,  two 
separate  SL)s  could  be  written.  Note  that  .ZEROES  is  required  in  the  empty  case  because 
ZE_R0  actually  is  modified.  Restoration  of  the  its  value  back  to  its  original  state  is  not 
piecisely  the  same  as  not  changing  it  all.  This  point  is  discussed  further  in  the  next 
chapter. 

The  environment  for  the  SDs  includes  PureCode.  This  provides  a terse  way  to  tie  the 
specification  of  GFREE  to  the  existence  of  the  executable  instructions  that  comprise 
GFREE  in  their  correct  locations.  The  environment  for  the  inner  SD  further  requires 
that  the  values  for  x,  FREE  and  ZERO  not  have  changed  since  the  inner  SD  was  added  to 
the  context.  Since  ZERO  and  FKEF  are  also  contained  on  the  modification  list  of  the 
inner  SD,  it  is  evident  that  application  of  the  inner  SD  will  cause  its  own  demise! 
There  is  no  harm  done,  however,  fer  the  inner  SD  is  added  to  a context  by  application 
of  the  outer  SD  and  is  intended  for  use  exactly  once.  Reapplication  of  the  outer  SD 
generates  a new  version  of  the  inner  SD,  tied  to  a different  instantiation  of  the  free 
buffer  list  Note  that  the  outer  SD  is  not  eliminated  from  a context  when  the  inner  SD 
is  applied 

• (Open  (pre:  (x  is  a buffer! ist  beginning  at  .FREE  and  .ZERO-0)) 

(mod: ) 

(env:  PurcCoriei 

(post:  (SD  (pre:  .UPC- top  .PC-GP REF/MEM+l  .CFREE-ra 
(ra  is  less  than  37777Q) 

(0  is  less  than  rail) 

(7FR0/HEM  is  less  than  37777Q) 

71  RO/NEf1x0 

(0  is  less  than  nfsd) 

. Nf  S=  nf  s 
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(nfs  is  less  than  177777Q)) 

(mod:  Q PC  A GFREE  GFREET  FREE  x ZERO  NFS) 

(env:  PureCode  x FREE  ZERO) 

(post:  . UPC^ top 

(if  (LENGTH  x) =0 
then  .PC=ra 

and  x is  a buffer  list  beginning  at 
.FREE 

and  . ZERO=0  and  .NFS=nfs 
else  .PC=ra+l  and  .NFS=nfs+l 
and  (FS  (y  z) 

(x  is  a permutation  of  <y>az 
and  y is  a packet  buffer 
and  z is  a buffer  I ist 
beginning  at  .FREE 
and  . ZERO=0 

and  A is  pointing  to  y°0 
and  GFREET  is  pointing  to 
y°0) 

( var  s : ra  nfs) ) ) 

(vars:  x) ) 

1 he  following  preds  were  added: 
pred:  \.ZERO=0) 
support:  ((ZERO)) 

pred:  (x  is  a bufferlist  beginning  at  .FREE) 
support:  ((OMEGA)) 


j _ taLP  care  of  the  requirement  that  x be  registered  in  the  place 
The  next  two  commands  take  care  of  the  q ^ Derive  command  is  a 

system  before  the  proof  of  the  inner  tQ  the  current  context  without  any 

pure,  premeditated  cheat;  it  simply  adds  i g t beginning  at  .FREE" 

~ - - — 

out  the  necessary  derivation. 

• (Derive  (Covering  BufferSpace  <x>)) 


The  following  preds  were  added: 
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pred:  (Covering  BufferSpace  <x>) 
supports  NIL 

• (NewDecompos i t i on  (Covering  BufferSpace  <x>)) 

The  following  preds  uerD  deleted: 

pred:  (x  is  a bufferlist  beginning  at  .FREE) 

support:  ( (OMEGA) ) 

The  following  preds  were  added: 

pred:  (x  is  a bufferlist  beginning  at  .FREE) 

support:  ((FREE  MEM°277Q)  (x) ) 


This  Open  command  begins  the  subproof  of  the  inner  SD.  At  this  point,  predicates  that 
are  added  to  the  context  are  no  longer  shown,  but  predicates  that  are  copied  from  a 
higher  context  to  the  new  context  because  of  an  intersection  between  the  modification 
list  and  the  environment  list  are  shown. 

• (Open  (pre:  .UPC-top  .PC=GFREE/NEf1+l  .GFREE-ra 
(ra  is  less  than  T7777Q) 

(0  is  less  than  ra+1) 

(ZERO/MEM  is  less  than  37777Q) 

ZERO/IIEri/0 

(0  is  less  than  nfs+1) 

. NFS-nf s 

(nfs  is  less  than  1 77777Q) ) 

(mod:  Q PC  A GFREE  GFREET  FREE  x ZERO  NFS) 

(env:  PureCode  x FREE  ZERO) 

(post:  .UPC=top 

(if  (LENGTH  xU0 

then  . PC^ra  and  x is  a bufferlist  beginning  at  .FREE 
and  .ZERO=0  and  .NFS=nfs 
else  .PC^ra+l  and  ,NFS=nfs+l 
and  (FS  (y  z 

(x  is  a permutation  of  <u>ez 
and  y is  a packet  buffer 
and  z is  a bufferlist  beginning  at 
.FREE 

and  .ZERO=0  and  A is  pointing  to  y>>0 
and  GFREET  is  pointing  to  y«0) 

(vars:  ra  nfs)) 
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The  following  preds  were  copied  to  the  new  context: 
pred:  (x  is  a buffer  list  beginning  at  .FREE) 
support:  ((FREE  NEf1<.277Q)  (x) ) 

pred:  (.ZERG-0) 
support:  ((ZERO)) 


5.7  Execution  of  the  first  instruction 


The  following  commands  begin  the  execution  of  GFREE.  The  first  command 
substitutes  the  address  of  GFREE  into  the  predicate  expressing  the  current  value  of  the 
program  counter.  The  simplification  rules  are  bypassed  for  substitution  because  they 
have  a tendency  to  simplify  in  the  wrong  direction.  In  this  case,  for  example, 
NEN»10512Q  is  substituted  for  GFREE  in  . PC-GFRFE/MEM+l.  The  substitution  results  in 
.PC=NEf1ol0512Q/NEI1+l.  If  the  simplification  rules  were  invoked,  the  simplifier  would 
try  to  "evaluate"  .PC  and  retrieve  the  value  GFREE/flEM+1;  the  result  would  be 
GFREE/MEM+1  -=105130.  While  this  is  a true  statement,  it  does  not  have  the  desired  effect 
of  changing  the  representation  of  the  current  value  of  the  program  counter. 
Consequently,  the  unsimplified  value  is  stored  away.  In  the  next  command,  the 
precondition  for  the  SD  includes  the  condition  that  . PC-10513Q  This  condition  is 
checked  by  invoking  the  simplifier  and  asking  if  the  expression  simplifies  to  T.  At  this 
point  the  evaluation  of  .PC  works  in  the  right  direction.  Before  the  two  sides  of  the 
equality  are  compared,  the  value  for  .PC  is  retrieved  and  automatically  reduced  to 
lowest  terms.  When  the  equality  check  takes  finally  takes  place,  10513Q  is  Just 
compared  against  10513Q  a.  d the  match  succeeds 

All  of  the  switches  are  turned  on  at  this  point.  In  addition  to  seeing  what  predicates 
added  and  removed  from  the  current  context,  we  also  see  what  predicates  are  found  by 
the  pattern  matcher 

• (Substitute  METM0S12Q  GFREE  .PC-1) 

The  pattern  matcher  returned: 
pred:  ( . PC-GFREE  /MEM-r  1 ) 
support:  ((PC)) 

The  following  preds  were  added: 
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pred:  (.PC-MtM»10512Q/MEn+l) 
support:  ((PC)) 

• (ApplylnstSU  (SO  (--  . MEM- (. PC) =1400400  S)  S) 

(pc  10S13Q) ) 

The  pattern  matcher  returned: 

pred:  (SO  (pre:  .UPOtop  .PC=pc  . MEMo  (. PC)  =1400400) 

(mod:  Q PC  A) 

(env: ) 

(post:  .UPC=top  .PC= (pc+1 ) ; 13  .A^0) 

(vars:  pc)) 
support:  NIL 

The  following  preds  were  deleted: 
pred:  ( . UF’C=  top) 
support:  ((UPC)) 

pred:  (.PC=GFREE/ttEM-*l) 
support:  ((PC)) 

pred:  (.PC=t1EM««10B12Q/riEM+l) 
support:  ((PC)) 

The  following  preds  were  added: 
pred:  ( . A- 0) 
support:  ((A)) 

pred:  (.PC-10S14Q) 
support:  ((PC)) 

pred:  (.UPC^top) 
support:  ((UPC)) 

• (ApplylnstSU  (SO  (--  (x  is  a buffer  list  beginning  at  y)  I)  I) 

(x  x y .FREE)) 

The  pattern  mat  her  returned: 

pred:  (SI)  (pre:  (x  is  a bufferlist  beginning  at  y) ) 

(mod: ) 

(env: ) 

(post:  (Subsetp  x BufferSpace) 

yx0 
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(y  is  teas  than  37777Q) 

(if  (LENGTH  x)*0 
then  y=ZERO/MEM 

else  x »0  is  a packet  buffer  and  y=x<>0o0/MEM 

and  x,l  is  a bufferlist  beginning  at  .x°0<>0)) 

(vars:  x y) ) 
support:  NIL 

The  following  preds  were  added: 
pred:  (if  (LENGTH  x)=0 

then  .FREE=ZERO/MEM 

else  x «0  is  a packet  buffer  and  .FREE'xn0o0/MEM 

and  x,l  is  a bufferlist  beginning  at  .xo0o0) 
support:  ((x)  (FREE  MEM.277Q1) 

pred:  (.FREE  is  less  than  377770) 
support:  ((FREE  MEM-277U)) 

pred:  (.FREE*0) 
support:  ((FREE  MEMo277Q)) 

pred:  (Subsetp  x Buf ferSpace) 
support:  NIL 


5.8  Consideration  of  an  empty  free  bufferlist 


The  next  Open  command  begins  the  consideration  of  ti  e case  in  which  the  free  buffer 
list  is  empty  when  GFREE  is  entered  From  this  point  on,  only  the  predicates  copied  to 
lower  contexts  during  an  Open  command  and  predicates  .ound  by  the  pattern  matcher 
are  shown. 

• (Open  (pre:  (LENGTH  x)=0) 

(mod:  x FREE  GFREE T GFREE  A PC  Q ZERO) 

(env:  OMEGA) 

(post:  .UPC'top  (LENGTH  x)*0  .PC=ra 

(x  is  a bufferlist  beginning  at  .FREE) 

. ZERO' 0 .NFS=nf s) 

(vara: ) ) 


n 


1 


The  following  preds  were  copied  to  the  new  context: 
pred:  (if  (IFNGTH  x)=0 

then  .FREE-ZERO/MEM 

else  x °0  is  a packet  buffer  and  .FREE*x<>0°0/HEH 

and  x,l  is  a bufferlist  beginring  at  ,xo0o0) 
support:  ( (x)  (FREE  MEM-277Q) ) 

( 

pred:  (x  is  a bufferlist  beginning  at  .FREE) 
support:  ((FREE  MEn°277Q)  (x) ) 

I 
\ 

pred:  (,ZERO=0) 
support:  ((ZERO)) 

j 

pred:  (.UPC- top) 
support:  ((UPC)) 

pred:  (.  PC- 1 0‘31 4Q ) 
support:  ((PC)) 

pred:  (.A=0) 
support:  ((A)) 

pred:  (.GFREE^ra) 
support:  ( (GFREE  MEM.10512a> ) 

pred:  (.FREE  is  less  than  37777Q) 
support:  ((FREF  NEf1«’277Q) ) 

pred:  (.FREFV0) 
support:  ((FREE  MEM«277Q) ) 

• (SinipleEval  (if  (If NOTH  x)«=0 
then  8 
else  8) ) 


The  prior  command  made  use  of  the  hypothesis  in  the  Open  command.  The  following 
ten  commands  execute  the  IMA  instruction.  Four  of  these  ten  apply  SDs  to  advance  the 
state.  The  other  six  simplify  the  state  to  derive  the  exact  precondition  required  by  the 
SDs.  In  the  future,  i expect  the  proposer  to  generate  these  steps  automatically. 

• (ApplylnstSD  (SO  (8  .MEM«(.PC) : 13, 10*0  8)  8)) 

The  pattern  matcher  returned: 

pred:  (SO  (pro:  .UPC=top  .MEM- (.PC) ; 13, 10*0) 

(mod:  Q) 

(cnv: ) 

(post:  . 0P= . MEM ■ ( . PC ) ; 1 3 , 1 0 .UPOador  . I -.MEM.  (.PC)  *15 
(if  .MEM" (.PC) "9=0 

then  .M=.MEM» (.PC) ; 8 

else  . M= . MEM" ( . PC) ; 8+ (LOGAND  .PC  377000Q))) 

(vars: ) ) 
support:  NIL 

• (ApplylnstSD  (SD  (--  .1=1  8)  8) 

(m  277Q) ) 

The  pattern  matcher  returned: 
pred:  (SO  (pre:  .UPC=addr  .1=1  .M=m) 

(mod:  UPC  1 M) 

(env: ) 

(post:  .UPC=addr  ,M=.MEM»m;13  . I = . MEMim»15) 

(vars:  ml) 
support:  MIL 

• (Substitute  FREE  MEM-277Q  .1=8) 

The  pattern  matcher  returned: 
pred:  ( . I =.MEM«277Q"15) 
support:  ((FREE  MEM"277Qi  (D) 

• (SuapDOTSEL  .FREE-15  .1=8) 

The  pattern  matcher  returned: 
pred:  ( . I =.FREF "15) 
support:  ((FREE  MEM.277Q)  M)) 
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• (Overlimit  ( - FREE ) “15  .1-8) 


The  pattern  matcher  returned: 
pred:  (.  I = (.FREE)  »i5) 
support:  ( (FREE  (1E(1-277Q)  (I)) 

• (ApplylnstSU  (SO  (--  .1=0  8)  8)) 

The  pattern  matcher  returned: 
pred:  (SO  (pre:  .UPC=addr  .1=0) 

(mod:  UPC) 

(env: ) 

(post:  .UPC=action) 

(vars: ) ) 
support:  NIL 

• (Substitute  FREE  (1E(1o2770  .(1=8) 

The  pattern  matcher  returned: 
pred:  ( . 11= . nEN-277Q;  13) 
support:  ((FREE  (1EM-277Q)  (0)) 

• (SuapDOTscgthru  .FREE;  13  .(1-8) 

The  pattern  matcher  returned: 
pred:  ( . (1= . FREE;  13) 
support:  ( " hEE  (1E(1o277Q)  (0)) 

• (Underlimit  ( .FREE) ; 13  .(1=8) 

The  pattern  matcher  returned: 
pred:  ( . 11=  (.FREE)  ;13) 
support:  ((FREE  MEM«>277Q)  ((1) ) 

• (ApplylnstSO  (SO  (--  .0P=11  8)  8) 

(pc  10S1AQ  m ZERO/flEd  a 0 b 0)) 

The  pattern  matcher  returned: 

pred:  (SO  (pre:  .UPC=action  .0P=U  .PC=pc  .A=a  ,(1=m  .(1F(1"m=b) 
(mod:  Q PC  A (1E(1®m) 

(env: ) 

(post:  .UPC=top  .PC=  (pc+1 ) ; 13  .A=b  .(1E(1®m=a) 

(vars:  pc  m a b) ) 
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support:  NIL 


7'he  program  counter  is  now  pointing  to  the  SNZ  instruction.  The  next  command  causes 
it  to  be  executed.  Because  the  contents  of  A are  known  to  be  0,  the  postcondition  is 
completely  simplified  to  Just  . PC=1051GQ.  Following  the  SNZ  instruction  is  the  JMP 
instruction  which  exits  from  GFREE.  Eight  commands  are  required,  four  of  which 
advance  the  computation  and  four  which  derive  consequences  between  computation 
steps. 


• (ApplylnstSO  (SO  (--  .MEn«(.PC)=101040Q  *)  I) 

(pc  1051SQ)) 

The  pattern  matcher  returned: 

pred:  (SO  (pre:  .0PC=top  ,PC=pc  .MEM» (.PC) =101 040Q) 

(mod:  Q PC) 

(env: ) 

(post:  .0PC=top  (if  . A=0 

then  . PC= (pc+1 ) ; 13 
else  .PC= (pc+2) ; 13) ) 

(vars:  pci) 
support:  NIL 

• (ApplylnstSO  (SO  (~  . NEN- (.PC) ; 13, 10*0)  *)) 

The  pattern  matcher  returned: 

pred:  (SO  (pre:  .0PC=top  . HEN®  ( .PC) ; 13, 10*0) 

(mod:  Q) 

(env: ) 

(poet:  . OP'.MEM"  (.PC) ; 13, 10  .UPC=addr  , I *= . MEM ( . PC ) »15 
(if  .MFM°(.PC)<>9=0 

then  .M=.f1EM«  (.PC)  ;8 

else  .n=.MEIi- (.PC)  ;8+  (LOGAND  .PC  377000Q) ) ) 

(vars: ) ) 
support:  NIL 

• (ApplylnstSO  (SD  (--  .1=1  .N=m)  I) 

(m  10512Q) ) 

The  pattern  matcher  returned: 
pred:  (SD  (pre:  ,UPC=addr  .1=1  ,N=m) 


81 


(mod:  UPC  I M) 

(rnv: ) 

(post:  .UPC=addr  .M=.riEH«m;  13  . U.nEn»in»15) 
(vars:  m) ) 
support:  NIL 

• (Substitute  GFREE  NEn=10512Q  .1=*) 

The  pattern  matcher  returned: 
pred:  ( . U.NEN"10S12Q"1S) 
support:  ( (GFREE  MEM"10S12a)  (1 ) ) 

• (SuapDOTSEL  .GFREE  =15  .1=#) 

The  pattern  matcher  returned: 

pred:  ( . I = . GFREE °1S) 

support:  ((GFREE  MEn-10S12a)  (I)) 

• (Substitute  ra  .GFREE  .1-8) 

The  pattern  matcher  returned: 
pred:  (. I = (.GFREE) -15) 
support:  ( (GFREE  MEM-10S12O)  (1 ) ) 

• (Over  limit  ra»lS  . 1=8) 

The  pattern  matcher  returned: 
pred:  ( . I =ra°lb) 
support:  ((D) 

• (ApplylnstSU  (SO  (--  .1=0  8)  8)) 

The  pattern  matcher  returned: 
pred:  (SO  (pre:  .UPC=addr  .1=0) 

(mod:  UPC) 

(rnv: ) 

(post:  .UPC=action) 

(vars: ) ) 
support:  NIL 

• (ApplylnstSU  (SO  (--  .0P=1  8)  f) 

(m  .REt1°10512Q;  13) ) 


82 


The  pattern  matcher  returned: 
pred:  (SO  (pre:  .UPC=actiori  «OP«=l  .(1=m) 
(mod:  Q PC) 

(env: ) 

(post:  .UPC=top  .PC=m) 

(vars:  m)) 
support:  NIL 


At  this  point,  GFREE  has  been  exited.  All  that  remains  is  to  show  that  the  present 
state  matches  the  postcondition  stated  in  the  Open  command.  The  first  command 
reconstructs  the  fact  that  x is  a bufferlist  beginning  at  ZERO/MEfl.  The  next,  four 
transform  . PC= . MEM  1 0B1 2Q ; 1 3 into  ,PC«=ra+l.  Finally,  .FREE  is  substituted  for 
ZERO/MEM  and  the  proof  is  closed. 


• (ApplyJnstSD  (SO  8 ( — (x  is  a bufferlist  beginning  at  y) ) &) 

(x  x y ZERO/MEN) ) 

The  pattern  matcher  returned: 
pred:  (SO  (pre:  (Subsetp  x BufferSpace) 
y*0 

(y  is  less  than  37777Q) 

(if  (LENGTH  x)^0 
then  y=ZER0/MEM 

else  x t>0  is  a packet  buffer  and  y*-xo0o0/MEH 

and  x,l  is  a bufferlist  beginning  at  .x»0o0)) 

(mod: ) 

(env: ) 

(post:  (x  is  a bufferlist  beginning  at  y) ) 

(vars:  x y) ) 
support:  NIL 

• (Substitute  GFREE  MEn<.10512Q  .PC=t) 

The  pattern  matcher  returned: 
pred:  ( . PC  = . MEM  ® 1 0S1 2Q ; 13) 
support:  ((GFREE  MEn»10512Q)  (PC)) 

• (SuapOOTsegthru  .GFREE;13  .PC=f) 

The  pattern  matcher  returned: 
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pred:  ( . PC= . GfREE ; 1 3) 

support:  ( (GFREE  MEM-10512Q)  (PC)) 


• (Substitute  ra  .GFREE  ,PC=8) 


The  pattern  matcher  returned: 
pred:  (.PC* (.GFREE) ; 13) 
support:  ( (GFREE  MEFM0512Q)  (PC)) 


• (Under  limit  ra;13  . PC-8 ) 


The  pattern  matcher  returned: 
pred:  (.PC=ra;13) 
support:  ((F’C)) 


• (Substitute  .FREE  ZERO/MEM  (x  is  a buffer  list  beginning  at  I)) 


The  pattern  matcher  returned: 

pred:  (x  is  a buffer  list  beginning  at  ZERO/tlEM) 

support:  ( ( x) ) 


• (Close) 


5.9  Consideration  of  a nonempty  free  bufferlist 


The  next  Op  .n  command  begins  a subproof  in  parallel  with  the  previous  subproof. 
The  modification  list  for  this  subproof  is  the  same  as  before,  with  the  exception  of  the 
addition  of  NFS.  All  of  the  clauses  copied  in  the  prior  subproof  are  also  copied  here, 
along  with  .N)  S=nfs  and  the  SD  proven  in  the  prior  subproof. 


After  the  proof  is  opened,  the  assumption  that  the  list  is  nonempty  is  exploited.  This 
will  add  "x°0  is  a packet  buffer",  ".FREE*. x"0»0/I1EI1"1  and 

"x.l  is  a bufferlist  beginning  at  . x°0o0"  to  the  context.  The  support  for  the 
last  clause  will  be  computed  as  (x,l  x«0«0l . Because  no  subdivisions  of  x are  listed  in 
the  place  grqih,  this  last  predicate  will  be  attached  to  the  node  for  x and  will  therefore 
be  subject  tu  deletion  if  any  part  of  x is  modified  Since  the  next  instruction  modifies 
the  first  word  of  the  first  buffer  on  x,  we  are  in  danger  of  losing  all  knowledge  about 
the  rest  of  x unless  we  can  subdivide  x and  break  our  knowledge  about  the  unmodified 
part  of  x into  terms  that  arc  independent  of  the  modified  part. 
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The  next  three  commands  prov’ri'.  the  required  scaffolding.  The  result  of  the  Derive 
command  is  the  subdivision  of  x we  need.  The  NewDecompos  i t i on  command  enters 
x °0  and  x,l  into  the  place  graph  and  the  Instant iateContente  command  gives  a 
name  to  the  current  value  of  .x°0«0.  All  that  remains  is  to  separate  the  knowledge 
about  x into  components  pertaining  to  x«0  and  x,l.  This  is  carried  out  Just  prior  to 
the  actual  exchange. 


• (Open  (pre:  (LENGTH  x)*0) 

(mod:  x FREE  GFREET  GFREE  A PC  Q ZERO  NFS) 

(env:  OMEGA) 

(post:  .UPC*top  (LENGTH  x)*0  .PC*=ra+l  .NFS*nfs+l 
(FS  (y  z) 

(x  is  a permutation  of  <y>ez 
and  y is  a packet  buffer 
and  z is  a bufferlist  beginning  at  .FREE 
and  .ZER0=3  and  A is  pointing  to  y»0 
and  GFREET  is  pointing  to  y»B))) 

(vars: ) ) 

The  following  preds  were  copied  to  the  new  context: 
pred:  (.NFS=nfs) 
support:  ((NFS  NEN-S00Q)) 

pred:  (if  (LENGTH  x)*0 

then  .FREE*ZERO/ttEM 

else  x o0  is  a packet  buffer  and  .FREE*xo0n0/HEf1 

and  x,l  is  a bjfferlist  beginning  at  .x"0»0) 
support:  ( (x)  (FREE  NEN«277Q)) 

pred:  (x  is  a bufferlist  beginning  at  .FREE) 
support:  ((FREE  f1Ef1«.277Q)  (x) ) 

pred:  (.ZERO*0) 
support:  ((ZERO)) 

pred:  (.UPC* top) 
support:  ((UPC)) 

pred:  (.PC*10514Q) 
support:  ((PC)) 

pred:  (.A*0) 
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• '*>’"■1  ' I II  I II 


suppor  t : ( (A) ) 

pred:  (.GFREE=ra) 

support:  ( (GFREE  NEN"10S12Q) ) 

pred:  (.FHEE  is  less  than  37777Q) 
support:  ( (F  REE  i'EM»277Q)) 

pred:  (.FREF*0) 
support:  ((FREE  NEHo277Q)) 

pred:  (SO  (pre:  (LENGTH  x)=0) 

(mod:  x FREE  GFREET  GFREE  A PC  Q ZERO) 

(env:  ONEGA) 

(post:  .UPC=top  (LENGTH  x)=0  ,PC=ra 

(x  is  a bufferlist  beginning  at  .FREE) 

. ZERO=0  .NFS-nfs) 

(vars: ) ) 
support:  ((ONEGA)) 

• (SimpleEval  (if  (LENGTH  x)=0 

then  8 
else  8) ) 

The  pattern  matcher  returned: 
pred:  (if  (LENGTH  x),0 

then  .FREE=ZERO/NEN 

else  x»0  is  a packet  buffer  and  . FREE«=x°0o0/MEN 

and  x,l  is  a bufferlist  beginning  at  .x°0»0) 
support:  ( ( x ) (F HEE  MEH»277Q)) 

• (Applylns'SD  (SO  8 (--  x=<x«0>9x, 1 ) 5) 

(x  x)) 

The  pattern  matcher  returned: 
pred:  (SO  (pre:) 

(mod: ) 

(env: ) 

(post:  x=<x»0>@x,l) 

(vars:  x) ) 
support:  NIL 

• (Derive  (Covering  x <x»0  x,l>)) 
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•'.sJie-’WfwSCT 


• (NeuDecomposi t ion  (Covering  x <x*8  x,l>)) 

• (Instant iateContents  x»0«0  p) 


The  I HA  instruction  is  now  ready  for  execution.  As  before,  several  commands  are 
required  to  wade  through  the  details  of  the  indirect  addressing  cycle.  Just  before  the 
actual  exchange  is  carried  out,  the  definition  of  "is  a buffer  I ist"  is  applied  to  reduce 
"x.l  is  a buffer  I ist  beginning  at  . x«0«0"  to  more  primitive  terms.  In  the 
course  of  the  application,  a!!  occurrences  of  . x*0«0  are  replaced  by  p because  p is 
known  to  be  the  current  value  of  . x»0«8.  The  result  is  that  none  of  the  new  clauses  are 
supported  by  either  x or  x»0;  only  x,l  is  needed.  Now  the  exchange  instruction  may  be 
executed  without  causing  information  to  be  lost. 


• (ApplylnstSD  (SD  (—  .HEM*  (.PC)  ;13, 10x0  *)  D) 

The  pattern  matcher  returned: 

pred:  (SD  (pre:  .UPC=top  .MEM«(.PC);13,10*8) 

(mod:  Q) 

(env: ) 

(post:  .OP-.HEH* (.PC) : 13,10  .UPC=addr  . U.HEH* (.PC) -IS 
(if  .MEM* (.PC) *9=0 

then  .M=.MEM»(.PC) ;8 

else  . M= . I1EM ■ ( . PC ) ; 8+  (LOGAND  .PC  377000Q) ) ) 

(vars: ) ) 
support:  NIL 

• (ApplylnstSD  (SO  (—  .1=1  *)  (—  m I) ) 

(m  277Q) ) 

The  pattern  matcher  returned: 
pred:  (SO  (pre:  .UPC=addr  .1=1  .M=m) 

(mod:  UPC  I H) 

(env: ) 

(post:  .UPC=addr  ,H=.HEH*m5l3  . 1 «.MEM»m»15) 

(vars:  m) ) 
support:  NIL 

• (Substitute  FREE  HEH-277Q  .1=*) 

The  pattern  matcher  returned: 
pred:  (.  N.HEH.277Q.15) 
support:  ((FREE  HEH-277Q)  (I)) 
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• (SuapDOTSEL  .FREE <.15  .1=*) 


The  pattern  matcher  returned: 
pred:  (.  1 =.FHEE<.15) 
support:  ((FREE  MEM-277Q)  (I)) 

• (Over  limit  (.FREE) -15  .1=*) 

The  pattern  matcher  returned: 
pred:  (.  1 = (.FREE)  <.15) 
support:  ((FREE  MEf1<.277Q)  (I)) 

• (ApplyinstSD  (SD  (—  .1=0  *)  »)) 

The  pattern  matcher  returned: 
pred:  (SD  (pre:  .UI’C=addr  .1=0) 

(mod:  UPC) 

(env: ) 

(post:  .UPC=action) 

(vars: ) ) 
support:  NIL 

• (Substitute  FREE  MEn«.277Q  .f1=S) 

The  pattern  matcher  returned: 
pred:  ( . M- . MEM »277Q ; 13) 
support:  ((FREE  MEM<.277Q)  (fl) ) 

• (SuapDOTscgthru  . FREE ; 1 3 .M=t) 

The  pattern  matcher  returned: 
pred:  (.M=. FREE; 13) 
support:  ((FREE  MEn»277Q)  (fl) ) 

• (Undcrl  imit  ( . F REF ) ; 1 3 .f1=S) 

The  pattern  matcher  returned: 
pr  ed:  (.M=  (.FREE) ; 13) 
support:  ((FREE  f1Ef1<>277Q)  (fl) ) 

• (ApplyinstSD  (SD  (--  (x  is  a bufferlist  beginning 

(x  x,l  y . x <>0 «>0 ) } 
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The  pattern  matcher  returned: 

pred:  (SD  (pre:  (x  is  a buffer  list  beginning  at  y) ) 

(mod: ) 

(env: ) 

(post:  (Subsetp  x BufferSpace) 
y*0 

(y  is  less  than  37777Q) 

(if  (LENGTH  x)=0 
then  y=ZER0/MEf1 

else  x°0  is  a packet  buffer  and  y=xo0«0/MEN 

and  x,l  is  a bufferli9t  beginning  at  .x»0»0)) 

(var  s:  x y) ) 
support:  NIL 

• (ApplylnstSD  (SD  (--  . 0P=1 1 I)  I ( — pc  m a b) ) 

(pc  1 051 AQ  m x»0«0/riEH  a 0 b p) ) 


The  pattern  matcher  returned: 

pred:  (SD  (pre:  .UPOaction  ,0P=11  .PC=pc  .A=a  .I1=m  . t1Ef1»ni=b) 
(mod:  G PC  A MEN-m) 

(env: ) 

(post:  .UPC=top  .PC=(pc+l) ; 1 3 .A=b  .HEf1°m=a) 

(var 9:  pc  m a b) ) 
support:  NIL 


The  program  counter  Is  now  pointing  to  the  SNZ  instruction.  This  time,  A contains  p, 
and  p is  known  to  be  different  from  0.  As  a consequence,  the  postcondition  of  the  SD 
simplifies  completely  and  .PC=10517Q, 

The  four  following  commands  execute  the  IRS  instruction.  The  only  derivation 
required  is  to  transform  .H=500Q  into  . M=NFS/MEM. 


• (ApplylnstSD  (SD  (—  &-101040Q)  t (--  pc)) 

(pc  105150) ) 

The  pattern  matcher  returned: 

pred:  (SD  (pre:  .UPC=top  .PC=pc  .MEN® (.PC) =1010400) 
(mod:  Q PC) 

(env: ) 
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(post:  .UPC=top  (if  . A-0 

then  .PC- (pc+1 ) ; 13 
else  .PC*  (pc+2) : 13) ) 

(vars:  pc)) 
support:  NIL 

• 'ApplylnstSO  (SD  (—  .hEFM.PC) ; 13, 10*0  *)  t )) 

The  pattern  matcher  returned: 

pred:  (SD  (pre:  .UPC-top  .NEh®  (.PC) ; 13,10*0) 

(mod:  Q) 

(cnv: ) 

(post:  . OP-.MEh® (.PC) ; 13, 10  .UPC-addr  . l=.hEh®(.PC) ®15 
(if  .MEh®(.PC) ®9=0 

then  .t1-.t1Eh»(.PC);8 

else  . M=.MEM» (. PC) ; 8+ (LOGAND  .PC  377000Q) ) ) 

(vars: ) ) 
support:  NIL 

• (ApplylnstSO  (SD  (--  .1=0  I)  I)) 

The  pattern  matcher  returned: 
pred:  (SD  (pre:  .UPC-addr  .1=0) 

(mod:  UPC) 

(env: ) 

(post:  .UPC-act ion) 

(vars: ) ) 
support:  NIL 

• (Makeindcxof  S00Q  .h=#) 

The  pattern  matcher  returned: 
pred:  (.M^S00Q) 
support:  ((h)) 

• (ApplylnstSO  (SO  (--  .OP-10  I)  « (—  m pc  v) ) 

(m  NFS/HE h pc  10517Q  v nfs)) 

The  pattern  matcher  returned: 

pred:  (SD  (pre:  .UPC-action  .OP-10  .h=m  .hEh®m=v  ,PC-pc) 

(mod:  Q PC  hEf1®m) 

(cnv: ) 

(post:  .UPC-top  .hEf1®m=  (v+1 ) ; 15  (it  .hEh®m-0 
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then  (.PC*pc+2) ; 13 
e I 9e  .PC* (pc+1 ) { 13) ) 


(vars:  n pc  vl) 
support:  NIL 


Because  the  IRS  instruction  can  skip  if  the  result  is  equal  to  zero,  it  is  necessary  to  show 
that  nfs+2  cannot  be  zero.  The  next  six  commands  derive  the  fact  that  .NFSffiO  and 
.PC=10520H 


• (ApplylnstSO  (SO  (--  (x  is  less  than  y) ) I) 

(x  nf s y 177777Q) ) 

The  pattern  matcher  returned: 
pred:  (SO  (pre:  (x  is  less  than  y) ) 

(mod: ) 

(env: ) 

(post:  (x+1  is  less  than  y+1)) 
(vars:  x y) ) 
support:  NIL 

• (Under  limit  (nfs+l):lS  .NFS*!) 

The  pattern  matcher  returned: 
pred:  (.NFS* (nf s+1 ) ; IS) 
support:  ((NFS  MEM<.500Q)) 

• (ApplylnstSO  (SO  (--  (0  is  less  than  x) ) 1) 

(x  nf s+1 ) ) 

The  pattern  matcher  retu-ned: 
pred:  (SO  (pre:  (0  is  less  than  x) ) 

(mod: ) 

(env: ) 

(post:  xx0) 

(vars:  x)) 
support:  NIL 

• (Substitute  .NFS  nfs+1  nfs+lx0) 

The  pattern  matcher  returned: 
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pred:  (nfs+l*0) 
support:  Nil 


• (Substitute  (nf s+l ) ; 15  .NFS  .NFS*0) 

The  pattern  matcher  returned: 

pred:  (.NFS*0) 

support:  ((NFS  nEM-5000)) 

• (CimpleEval  (if  (nf s+l ) ; 15=0 

then  S 
else  I) ) 

The  pattern  matcher  returned: 
pred:  (if  (nf s+ 1 ) ; 1S= 0 

then  ( . PC=10S21Q) ; 13 
else  . PC=10520Q) 
support:  ((PC)) 

! 

I 

The  second  exchange  instruction  is  now  ready  for  execution.  By  this  time,  very  little 
work  is  required.  The  key  facts  are  that  .A=p  and  .FREE=x°0»0/f1EM. 


• (ApplylnstSO  (SD  (—  . MEM* ( . PC) ; 13, 10/0  *)  !)) 

The  pattern  matcher  returned: 

pred:  (SD  (pre:  .UPC=top  . HEIM. PC);13, 10*0) 

(mod:  Q) 

(env: ) 

(post:  .OP=.MEM»(.PC);13,10  .UPC=addr  . I =.  MEM«>  ( . PC)  "15 
(if  .NEMo (.PC)  ®9*-0 

then  .(l-.flEflo (.PC)  ;8 

else  .N=.f1EMo(.PC)  ;8+(LDGAND  .PC  377000Q) ) ) 

(var s: ) ) 
support:  NIL 

• (ApplylnstSO  (SD  (--  .1=0  *)  t)) 

The  pattern  matcher  returned: 
pred:  (SD  (pre:  .DPC>-addr  .1*0) 

(mod:  DPC) 


s 

t 


(env: ) 

(post:  .UPC-action) 

(vars: ) ) 
support:  NIL 

• (Nakeindexof  277Q  . f1=S ) 

The  pattern  matcher  returned: 
pred:  (.M-277Q) 
support:  ((II)) 

• (ApplylnstSO  (SO  (—  .OP-11  I)  * (—  pc  m a b) ) 

(pc  10520Q  m FREE/MEM  j»  p b x*0<>0/MEM)) 

The  pattern  matcher  returned: 

pred:  (SO  (pre:  .UPC-action  .OP-11  .PC-pc  .A-a  . M-m  .MEM»m«b) 
(mod:  Q PC  A MEM*m) 

(env: ) 

(post:  .UPC-top  .PC- (pc+1 ) ; 13  .A-b  .f1EH«m«a) 

(vars:  pc  m a b ) ) 
support:  NIL 


The  STA  instruction  is  now  executed. 


• (ApplylnstSO  (SO  (—  .MEM* (.PC) ; 13, 10x0  t)  D) 

The  pattern  matcher  returned: 

pred:  (SO  (pre:  .UPC-top  ,MEM*(.PC) ;13,10*0) 

(mod:  Q) 

(env: ) 

(post:  . OP-.MEM* (.PC) ; 13, 10  .UPC-addr  . I-.MEM* (.PC) *15 
(if  .MEM* (.PC) *9-0 

then  .M- .MEM* ( . PC) ;8 

else  .M-.MEM*(.PC);8-*  (LOGANO  .PC  377000Q) ) ) 

(vars: ) ) 
support:  NIL 

• (ApplylnstSO  (SO  (--  .1-0  I)  •)) 

The  pattern  matcher  returned: 
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pred:  (SO  (pre:  . UPC=addr  .1=0) 

[ (mod:  UPC) 

(env: ) 

(post:  .UPC=action) 

(vars:)) 
support:  NIL 

\ • (Makeindexof  1 051  IQ  .M=f) 

The  pattern  matcher  returned: 
pred:  (.M-105110) 
support:  ((d)) 

• (ApplylnstSD  (SO  (—  .0P=4  t)  «) 
l (m  GFREET/I1EN  pc  10S21Q)) 

The  pattern  matcher  returned: 
pred:  (SO  (pre:  .UPC=action  .0P=4  .M=m  .PC=pc) 
(mod:  Q PC  MEM»m) 

(env: ) 

(post:  .UPC=top  . PC=  (pc-tl ) 5 13  .MEM«m=.A) 
(vars:  m pc) ) 
support:  NIL 


The  IRS  Instruction  to  Increase  the  return  address  by  1 is  now  executed. 

• (ApplylnstSO  (SO  (--  .MEfl-(.PC) ; 13.10^0  *)  D) 

The  pattern  matcher  returned: 

pred:  (SO  (pre:  .UPC=top  . MEM*  (.  PC) ; 13, 10*0) 

(mod:  Q) 

(env: ) 

(post:  .0P=. MEM.  (.PC)  -.13.10  .UPC=addr  . N. MEM. (.PC) -IS 
(if  .MEM.  (.PC) *9=0 

[ then  . M=.MEM«(.PC) ;8 

else  .M=.MEM« (.PC) ;8+(L0GAN0  .PC  377000Q))) 

(vars: ) ) 
support:  NIL 

• (ApplylnstSO  (SO  (--  .1=0  I)  «) ) 
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The  pattern  matcher  returned: 
pred:  (SO  (pre:  .UPC*addr  . I -=0) 

(mod:  UPC) 

(env; ) 

(post:  .UPC*action) 

(vars: ) ) 
support:  NIL 

• (hakeindexof  10512Q  . t ) 

The  pattern  matcher  returned: 
pred:  (.M-105120) 
support:  ( (M) ) 

• (ApplylnstSO  (SO  (--  .OP*10  I)  S (--  m pc  v ) ) 

(m  GFREE/MEU  pc  10522Q  v r a)) 


The  pattern  matcher  returned: 

pred:  (SO  (pre:  .UPC*action  .OP*10  .(1*m  .MEfl»m*=v  .PC*pc) 

(mod:  Q PC  f1EM«>m) 

(env: ) 

(post:  .UPC*top  .(1EI1»m=  (v+1 ) ; 15  (if  .MEMi>in*0 

then  (.PC=pc+2) : 13 
else  .PC* (pc+1 ) ; 13) ) 


(vars:  m pc  v) ) 
support:  NIL 


As  with  the  incrementing  of  NFS,  it  is  necessary  to  show  that  the  result  of  Incrementing 
GFREE  is  not  zero.  The  next  six  commands  establish  that  ,PC*10523Q  and  that 
.GFREE-ra+1. 


• (ApplylnstSO  (SO  (--  (*  is  less  than  y) ) S) 
(x  ra  y 37777Q) ) 

The  pattern  matcher  returned: 
pred:  (SO  (pre:  (x  is  less  than  y) ) 

(mod: ) 

(env: ) 

(post:  (x+1  is  less  than  y+ 1 ) ) 
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(vars:  x y) ) 
supports  NIL 

• (Under  limit  (ra+l);15  .GFREE=t) 

The  pattern  matcher  returneds 
pred:  (.GFREE= (ra+1 ) ; IS) 
support:  ( (GFREE  MErM0512Q) ) 

• (ApplylnstSD  (SO  t — (0  is  less  than  x))  •) 

(x  ra+1)) 

The  pattern  matcher  returneds 
pred:  (SO  (pres  (0  is  less  than  x)) 

(mods ) 

(cnv: ) 

(posts  x/0) 

(varss  x)) 
supports  NIL 

» (Substitute  .GFREE  ra+1  ra+l*0) 

the  pattern  matcher  returneds 
pred:  (ra+l*0) 
support:  NIL 

• (Substitute  (ra+1); 15  .GFREE  . GFREE *0) 


The  pattern  matcher  returneds 

pred:  (. GFREE *0) 

supports  ((GFREE  MErM0512Q) ) 

• (SimpleEval  (if  (ra+1); 15=0 
then  t 
else  I) ) 

The  pattern  matcher  returneds 
pred:  (if  (ra+1); 15=0 

then  (.PC=10524Q) ; 1 3 
else  .PC=10523Q) 
supports  ((PC)) 


The  JMP  to  exit  GFREE  is  now  ready  for  execution.  Because  the  jump  is  indirect 
through  GFREE,  bit  15  of  the  value  in  GFREE,  i.e.  ra+1,  must  be  shown  to  be  zero. 


• (ApplylnstSO  (SO  (—  .f1Ef1°  (.PC) ; 13, 13*0  S)  I) ) 

The  pattern  matcher  returned: 

pred:  (SO  (pre:  .UPC=top  .MEfM.PC)  ;13,10*0) 

(mod:  Q) 

(env: ) 

(post:  . 0P«= . MEfl o ( . PC ) ; 13, 10  .UPC=addr  ..  .(lEfl- (.PC)  »15 
(if  .MEno(.PC)»9=0 

then  . M= . MEM «>  (.PC)  ;8 

else  . M= . MEM » ( . PC ) s 8+  (LDGAND  .PC  377000Q))) 

(vars: ) ) 
support:  NIL 

• (Makeindexof  10512Q  .f1=t) 

The  pattern  matcher  returned: 
pred:  (.M-10&12Q) 
support:  ((M)) 

• (ApplylnstSO  (SO  (—  .1=1  .M=m)  *) 

(m  GFREE /MEM) ) 

The  pattern  matcher  returned: 
pred:  (SO  (pre:  .UPC=addr  .1=1  .M=m) 

(mod:  UPC  I M) 

(env: ) 

(post:  .UPC=addr  .M=. HEM»m;  13  . I=.MEN>>m»15) 

(vars:  m)) 
support:  NIL 

• (ApplylnstSO  (SO  ( — (x  is  less  than  y ) ) I) 

(x  ra  y 37777Q) ) 

The  pattern  matcher  returned: 
pred:  (SO  (pre:  (x  is  less  than  y)) 

(mod: i 
(env: ) 

(post:  (x+1  is  less  than  y+1)) 

(vars:  x y) ) 


support:  NIL 


• (Overlimit  (ra+l»°15  .1=1) 

The  pattern  matcher  returned: 
pred:  (.  1 = (ra-il)  ®15) 
support:  ((D) 

• (ApplylnstSD  (SD  (--  .1=0  I)  D) 

The  pattern  matcher  returned: 
pred:  (SO  (pre:  .UPC=addr  .1=0) 

(mod:  UPC) 

(env: ) 

(post:  . UPC=act Ion) 

(var s: ) ) 
support:  NIL 

• (Underlimit  (ra+Djl3  .(1=8) 

The  pattern  matcher  returned: 
pred:  ( . (1=  (ra+1 ) ; 13) 
support:  ((d)) 

• (ApplylnstSO  (SO  (--  .0P=1  8)  t (—  m) ) 

(m  raD) ) 

The  pattern  matcher  returned: 
pred:  (SO  (pre:  .UPC=action  .0P=1  ,(1=m) 
(mod:  Q PC) 

(cnv: ) 

(post:  .UPC=top  ,PC=m) 

(vars:  m)) 
support:  NIL 


Execution  is  complete  at  this  point.  Before  the  subproof  can  be  closed,  however,  each  of 
the  clauses  in  the  postcondition  of  the  goal  must  be  derived.  These  are  straightforward. 
The  ForSome  command  produces  the  existential  generalization  of  the  specific  case 
proven  by  the  system.  This  exactly  matches  the  form  required  in  the  postcondition  of 
the  goal  and  subproof  is  closed. 
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• (ApplylnstSO  (SO  8 (--  (x  is  pointing  to  y) ) 8) 
(x  A y xo0>0) ) 


The  pattern  matcher  returned: 
pred:  (SO  (pre:  .x^y/HEM) 

(mod: ) 

(env: ) 

(post:  (x  is  pointing  to  y) ) 
(vars:  x y) ) 
support:  NIL 


• (ApplylnstSO  (SO  8 (--  (x  is  pointing  to  y) ) 8) 
(x  GFREET  y x»0»0)) 

The  pattern  matcher  returned: 
pred:  (SO  (pre:  . x«=y/f1Efl) 

(mod: ) 

(env: ) 

(post:  (x  is  pointing  to  y) ) 

(vars:  x y) ) 
support:  NIL 


• (ApplylnstSO  (SO  8 ( — (x  is  a permutation  of  <x°0>»x,l))  8) 

(x  x) ) 


The  pattern  matcher  returned: 
pred:  (SO  (pre:  x«=<x«>0>ax,  1 ) 

(mod: ) 

(env: ) 

(post:  (x  is  a permutation  of  <*®0>®x,l)) 

(vars:  x) ) 
support:  NIL 

• (ApplylnstSO  (SO  8 (--  (x  is  a bufferlist  beginning  at  y) ) 8) 
(x  x,  1 y p) } 

The  pattern  matcher  returned: 
pred:  (SO  (pre:  (Subsetp  x BufferSpace) 
y*0 

(y  is  less  than  37777Q) 

(if  (LENGTH  x) =0 
then  y*ZER0/nEf1 
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else  x»0  is  a packet  buffer  and  y=xo0o0/MEf1 

and  x,l  is  a buffer  list  beginning  at  .xd0«0)) 

(mod: ) 

(env: ) 

(post:  (x  is  a bufferlist  beginning  at  y) ) 

(vars:  x y) ) 
support:  NIL 

• (Substitute  .FREE  p (x,l  is  a bufferlist  beginning  at  p) ) 

The  pattern  matcher  returned: 

pred:  (x,l  is  a bufferlist  beginning  at  p) 

support:  ((x,l)) 

• (ForSome  (y  2) 

(x  is  a permutation  of  <y>®z  and  y is  a packet  buffer 

and  2 is  a bufferlist  beginning  at  .FREE  and  . ZERO*=0 
and  A is  pointing  to  y»0  and  GFREET  is  pointing  to  y»0) 
(y  x"0  2 x, 1 ) ) 

• (Close) 


At  this  point,  the  superior  context  is  restored  and  the  program  counter  and  other  parts 
of  the  state  description  are  reset  to  Jusl  after  the  first  instruction.  The  only  changes  to 
the  current  context  are  the  addition  of  two  SDs,  one  which  states  how  execution  would 
proceed  if  the  free  buffer  list  were  empty  and  one  which  states  how  execution  would 
proceed  if  the  free  buffer  list  were  not  empty. 

These  two  SDs  are  now  combined  into  a single  SD  using  the  CombineCases  command. 
The  precondition  of  the  resulting  SD  is  Just 

(LENGTH  x) =0  or  (LENGTH  x)*0 


This  is  a specific  Instance  of  a tautology,  and  that  specific  instance  is  then  derived  for 
use  in  applying  this  SD. 


• (CombineCases  (SO  ( — (LENGTH  x)«0  t)  I) 
(SD  (—  (LENGTH  x)*0  *)  *)) 

The  pattern  matcher  returned: 
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pred:  (SO  (pre:  (LENGTH  x)*0) 

(mod:  x FREE  GFREET  GFREE  A PC  Q ZERO  NFS) 

(env:  OMEGA) 

(post:  .UPC'top  (LENGTH  x)*0  ,PC*ra+l  .NFS^nfe+i 
(FS  (y  2) 

(x  is  a permutation  of  <y>az 
and  y is  a packet  buffer 
snd  2 is  a buffer  list  beginning  at  .FREE 
and  . ZERO=0  and  A is  pointing  to  y°0 
and  GFREET  is  pointing  to  y>0))) 

(vars: ) ) 
support:  ((OMEGA)) 


pred:  (SO  (pre:  (LENGTH  x)*0) 

(mod:  x FREE  GFREET  GFREE  A PC  Q ZERO) 

(env:  OMEGA) 

(post:  .UPC-top  (LENGTH  x)«0  .PC=ra 

(x  is  a bufferlist  beginning  at  .FREE) 
. ZERO=0  .NFS-nfs) 

(vars: ) ) 
support:  ((OMEGA)) 


• (ApplylnstSD  (SO  t ( — (a=0  or  ax0))  &) 

(a  (LENGTH  x))) 

The  pattern  matcher  returned: 
pred:  (SD  (pre:) 

(mod: ) 

(env: ) 

(post:  (a=0  or  a*0) ) 

(vars:  a)) 
support:  NIL 

• (ApplylnstSD  (SO  U) 


The  pattern  matcher  returned: 

pred:  (SD  (pre:  ((LENGTH  x)«0  or  (LENGTH  x)*0)) 

(mod:  x FREE  GFREET  GFREE  A PC  Q ZERO  NFS) 

(env:  OMEGA) 

(post:  (.UPC'top  and  (LENGTH  x)«0  and  .PC«ra 

and  x is  a bufferlist  beginning  at  .FREE 
and  .ZERO«0  and  .NFS«nfs  or  .UPC»top 
and  (LENGTH  x)*0 
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and  .PC*ra+l  and  .NFS«=nfs4l 
and  (FS  (y  z) 

(x  is  a permutation  of  <y>az 
and  y is  a packet  buffer 
and  z is  a buffer  list  beginning  at 
.FREE 

and  . ZER0=0  and  A is  pointing  to  y«0 
and  GFREET  is  pointing  to  yo0] 


(vars: ) ) 
supports  ((OMEGA)) 


Execution  of  GFREE  is  now  complete  and  the  proofs  corresponding  to  both  the  inner 
and  outer  SDs  in  the  specification  of  GFREE  can  now  be  closed  without  further  work. 


• (Close) 

• (Close) 
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6.  Conclusions  and  Future  Directions 


Beyond  the  particular  formulations  presented  here,  there  are  number  of  concepts  that 
have  emerged  in  my  mind  as  basic  perceptions  about  program  verification. 

The  first  perception  is  that  the  way  to  specify  the  behavior  of  a (sequential)  program  is 
in  terms  of  transitions  between  pairs  of  states.  Using  transitions  to  specify  behavior 
provides  a uniform  mechanism  for  treating  both  known  facts  and  desired  intentions. 
The  action  of  the  individual  instructions  can  be  characterized  in  terms  of  state 
transitions,  and  these  specifications  can  serve  the  role  of  axioms  for  a proof.  The 
intended  action  of  the  whole  program  can  also  be  formulated  as  a (set  of)  transition(s)  to 
be  proven.  State  deltas,  of  course,  serve  just  this  purpose. 

Perception  two  is  proofs  should  be  structured.  By  a "structured”  proof,  1 mean  the 
following  idea.  A proof  of  correctness  of  a program  consists  of  taking  the  SDs  for  the 
individual  instructions  and  combining  them  into  SDs  which  cover  execution  of 
sequences  of  instructions.  This  composition  process  is  continued  until  the  SDs  which 
describe  the  intended  behavior  of  the  whole  system  are  proven.  These  proofs  should 
fall  into  three  basic  patterns,  sequential  proofs,  proofs  by  cases,  and  inductive  proofs. 

In  a sequential  proof,  there  are  two  SDs.  The  postcondition  of  the  first 
leaves  the  machine  in  a state  that  satisfies  the  precondition  of  the  second. 

These  two  SDs  yield  a new  SD  formed  from  the  precondition  of  the  first 
and  the  postcondition  of  the  second.  This  pattern  of  reasoning  applies 
directly  to  straightline  code. 

In  a proof  by  cases,  the  code  under  consideration  contains  conditional 
execution  sequences  or  case  statements.  The  preconditions  of  the  given  SDs 
represent  alternative  possibilities.27  The  SDs  are  combined  by  taking  the 
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c These  preconditions  will  usually  be  disjoint  from  each  other,  but  this  is  not  a 
requirement.  The  most  common  case  for  the  preconditions  of  two  SDs  to  overlap  is  for  one  of 
them  to  specify  a short  segment  of  computation  and  the  other  to  specify  a longer  segment. 
Kach  SDs  that  was  derived  in  the  last  chapter  has  a precondition  that  is  strictly  stronger  than 
one  of  the  input  SDs.  "Strictly  stronger"  means  that  it  logically  implies  the  precondition  of  the 
input  SD.  The  fact  that  an  interpretation  already  exists  for  sets  of  SDs  which  have 
overlapping  preconditions  means  that  any  al tempt  to  extend  the  use  of  SDs  to  model 
concurrent  systems  will  need  to  use  some  mechanism  other  than  sets  of  SDs  which  apply  to  the 
same  states. 
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disjunction  of  the  preconditions  as  the  new  precondition  and  the 
disjunction  of  the  postconditions  as  the  new  postcondition. 


In  an  inductive  proof,  the  goal  is  to  prove  that  the  operation  of  a loop  is 
correct.  One  SD  covers  the  operation  of  the  body  of  the  loop,  and  the  other 
covers  the  test  which  determines  whether  the  loop  is  to  be  repeated  or 
exited.  The  resulting  SD  covers  the  complete  operation  of  the  loop  and 
(usually)  is  written  in  terms  of  some  parameter  that  governs  the  number  of 
times  the  loop  is  traversed.  The  induction  proof  has  two  parts.  The  first 
part  proves  that  the  operation  of  the  loop  is  correct  for  the  minimal  value 
of  the  parameter.  The  second  part  assumes  that  the  operation  of  the  loop  is 
correct  for  all  values  of  the  parameter  below  the  value  being  considered  and 
shows  that  the  operation  of  the  loop  changes  the  state  into  a similar  one 
with  a smaller  value  of  the  parameter.  The  parameter  must  be  chosen  from 
a well-ordered  set  to  give  substance  to  the  notions  of  ’’minimal”  and 
"smaller”  and  to  make  use  of  the  properties  of  mathematical  induction. 

Perception  three  is  that  the  form  of  the  proof  and  the  form  of  the  program  need  not 
bear  strong  resemblance.  Efficient  use  of  space  or  time  frequently  demands  that  the 
syntactic  structure  of  the  program  be  quite  different  from  the  conceptual  structure. 
Some  writers  advocate  that  the  structure  of  the  program  should  exactly  reflect  the 
structure  of  the  proof.  When  faced  wnh  the  limitations  in  programming  languages 
which  lead  programmers  to  perturb  the  organization  of  a program  to  achieve  desired 
performance  goals,  these  writers  argue  that  the  programming  language  is  deficient  and 
should  be  changed.  My  own  position  is  that  better  programming  languages  are,  of 
course,  desirable,  but  no  compiler  can  be  smart  enough  to  generate  optimal  code  from 
the  most  readable  statement  of  the  algorithm.  As  a consequence,  1 believe  proofs  should 
not  be  bound  int.mately  with  the  structure  of  the  programming  language. 

Perception  four  is  that  it  is  reasonable  to  ask  the  programmer  to  supply  the  proof  along 
with  the  program.  Programming  is  a constructive  process,  and  the  person  most 
knowledgeable  about  the  interaction  of  the  parts  of  the  program  is  the  person  who  put 
it  together  in  the  first  place.  It  is  sometimes  argued  that  proving  a program  correct  is 
much  harder  than  writing  and  debugging  the  program  to  make  it  correct  in  the  first 
place.  This  seems  like  pure  nonsense  to  me.  In  order  for  the  programmer  to  write  and 
debug  the  program  in  the  first  place,  he  must  have  had  an  understanding  of  why  the 
program  would  accomplish  its  goals.  To  be  sure,  his  understanding  is  informal  and  not 
written  out  in  terms  acceptable  to  a program  verification  system.  Consequently,  there  is 
some  distance  to  be  covered  when  we  ask  that  formal  proofs  be  carried  out  when  a 
program  is  written  However,  this  distance  is  primarily  one  of  building  a language  for 
the  programmer  to  communicate  his  understanding  of  what  he  must  already  know. 
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Perception  five  is  that  it  is  at  feast  as  important  to  prove  that  a program  actually 
progresses  to  an  expected  point  as  it  is  to  prove  that  the  result  is  correct  when  it  gets 
there.  This  concept  is  usually  labeled  termination,  but  1 think  it  is  more  appropriate  to 
think  in  terms  of  progress.  Many  programs,  e.g.  operating  systems,  don’t  really 
terminate.  They  do,  however,  progress  from  one  known  state  to  the  next,  and  the  proof 
that  each  of  these  states  is  actually  reached  is  of  great  concern.  The  idea  of  a set  of 
"interesting"  states  instead  of  just  an  initial  state  and  a final  state  was  implied  in  the 
first  perception  by  the  use  of  a set  of  transitions  instead  of  just  a single  transition. 
Proving  that  programs  progress  as  intended  comes  for  free  in  the  proof  patterns 
outlined  in  perception  two.  This  is  in  marked  contrast  to  the  usual  separation  of  proofs 
of  correctness  from  proofs  of  termination  when  Floyd’s  method  is  used. 


Perception  six  relates  to  the  content  of  the  state  descriptions  that  make  up  the  pre-  ar<u 
postconditions  of  a SD.  These  should  be  as  general  as  possible.  Facts  which  may  be 
true  in  both  the  pre-  and  postcondition  but  which  are  not  necessary  to  the  correct 
operation  of  the  code  covered  by  the  SD  should  not  be  included.  For  example,  if  an 
initial  value  is  stored  into  a cell  early  in  a program  and  the  value  is  not  used  until  much 
later,  the  SDs  that  cover  the  loops,  subroutines  and  sequential  segments  in  between  these 
points  should  not  have  to  mention  the  variable  at  all,  much  less  retain  its  value. 


Perception  seven  is  that  no  state  information  should  be  hidden.  Quite  a bit  of  trouble 
is  caused  by  prett  'ding  that  machines  have  "automatic"  mechanisms  for  invoking 
subroutines,  iterating  through  loops,  or  remembering  where  the  next  data  item  is 
located.  I have  never  found  any  way  to  represent  these  activities  without  keeping  in 
mind  that  there  was  some  part  of  the  machine  devoted  to  keeping  track  of  the  state. 

Perception  eight  is  that  there  must  be  a separate  way  to  refer  to  the  name  of  a place  and 
to  the  current  contents  of  that  place.  Arguments  about  indirect  addressing,  list 
processing,  program  modification  and  other  matters  depend  upon  this  distinction  very 
strongly. 


Beyond  these  perceptions  there  are  also  a number  of  concrete  ideas  which  point  the  way 
for  improvement  in  both  the  theory  and  the  implementation. 


6.1  Theoretical  issues 


The  most  significant  hole  in  the  present  theory  is  the  absence  of  any  mechanism  to 
handle  concurrent  processes.  The  present  formulation  of  state  deltas  is  strongly 
dependent  on  the  assumption  that  only  one  active  agenv  is  modifying  the  state  of  the 
system,  and  that  it  is  sufficient  to  know  what  changes  that  agent  is  making  to  know  all 
the  changes  that  can  possibly  be  made.  At  any  given  point  in  time,  only  a single 
"future”  is  possible.  If  more  than  one  state  delta  happens  to  be  applicable,  it  is 
understood  that  one  of  them  carries  the  computation  farther  than  the  other. 

To  extend  the  present  theory  to  handle  concurrent  systems,  several  modeling  questions 
have  to  be  answered,  Are  the  concurrent  systems  to  be  composed  of  a small  or  large 
number  of  processors?  If  the  number  is  small,  we  can  imagine  that  each  of  the 
processors  can  have  its  own  set  of  state  deltas.  On  the  other  hand,  If  the  system  consists 
of  a large  number  of  identical  or  near  identical  processors,  then  some  scheme  is 
necessary  to  parameterize  the  SDs  and  perhaps  parameterize  the  Information  in  the 
contexts  in  the  proof  system.  In  either  case,  synchronization  of  the  concurrent  systems 
must  be  designed  properly. 

How  do  the  processors  connect  to  each  other  and  what  form  Is  their  communication?  If 
the  communication  is  restricted  to  signalling  with  semaphores  and  highly  disciplined  use 
of  shared  places,  then  some  of  the  more  modern  formalisms  may  be  applicable.  Brinch- 
Hansen,  Dijkstra,  Estrin,  Hoare  and  many  others  advocate  that  systems  should  be  built 
with  very  restrictive  rules  governing  the  form  of  interprocess  communication  that  Is 
provided  For  example,  Estrin  and  his  coworkers  advocate  separate  explicit  mechanisms 
governing  control  and  associated  data  flow  between  modular  subsystems.  Existing 
systems,  and  many,  many  systems  yet  to  be  built,  however,  use  simple  shared  places  with 
no  built-in  r estrictions  on  the  access  to  these  shared  places  by  the  processors.  Usually 
these  systems  do  adhere  to  a set  of  rules  governing  the  communication,  but  the  rules  are 
not  inherent  in  the  structure  One  of  the  more  important  facts  to  prove  about  these 
kinds  of  systems  is  that  they  compute  the  same  result  no  matter  how  fast  the  processors 
run.  If  the  processors  do  have  a discipline  which  guarantees  this  fact,  then  the  p.oof  of 
uniqueness  of  the  result  will  make  use  of  the  conventions  followed  by  the  several 
processors. 

Considering  the  case  of  a small  number  of  processors  which  are  interconnected  by 
shared  places,  we  can  see  some  of  the  changes  in  the  present  theory  that  will  be 
necessary.  State  deltas  now  contain  two  lists  of  places,  one  which  shows  what  set  of 
places  may  be  modified  during  the  computation  and  one  which  shows  which  set  must 
not  have  changed  since  the  SL)  was  proven  For  concurrent  systems  with  shared  places, 
it  seems  necessary  to  add  a similar  list  to  show  which  places  are  referenced  during  the 
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computation.  If  two  processors  are  operating  arid  one  of  them  is  modifying  a place  tt.n 
the  other  is  either  modifying  or  reading,  the  result  may  be  unpredictable.  If  the  only 
concurrent  use  of  shared  places  is  that  more  than  one  process  may  be  reading  from  the 
same  location,  then  no  conflict  arises  and  the  two  operations  may  proceed  in  any  order. 


When  more  than  one  result  is  possible  because  of  the  order  of  execution,  some  scheme  is 
necessary  to  examine  all  possible  outcomes.  The  usual  problem  with  this  approach  is 
that  the  number  of  cases  grows  exponentially  and  becomes  intractable.  The  only  hope 
for  success  is  to  lump  the  cases  into  large  classes  that  behave  similarly.  Showing  that  all 
cases  lumped  into  the  same  class  do  have  the  same  effect  would  need  to  be  proven,  as 
well  as  proving  that  each  of  the  classes  behaves  appropriately.  Two  ideas  seem  essential 
for  this  approach  to  succeed.  First,  some  notion  of  "indivisible  action"  needs  to  be 
included  in  the  formalism.  As  presently  formulated,  state  deltas  have  no  "grain  size". 
Some  set  of  SDs  is  introduced  into  the  proof  system  from  the  description  of  the  machine, 
but  nothing  prohibits  the  introduction  of  other  SDs  which  cover  smaller  units  of 
computation.  In  order  to  know  what  all  the  possible  orders  are  among  a set  of 
competing  processors,  some  notion  of  "grain  size"  is  crucial. 


Induction  is  the  idea  that  seems  necessary  here.  Each  lumping  of  a set  of  possible 
execution  sequences  into  a single  class  is  probably  based  on  an  argument  that  the  longer 
execution  sequences  reduce  to  a previously  considered  case  after  the  first  one  or  two 
steps  have  been  taken.  As  we  saw  with  sequential  operation,  the  ability  to  apply  normal 
induction  rules  to  state  deltas  is  extremely  powerful  and  1 would  hope  that  a similar 
mechanism  would  emerge  in  the  extension  of  the  theory  for  concurrent  operation. 


The  present  formulation  of  the  modification  list  raises  an  Issue.  At  present,  the 
semantics  of  a state  delta  say  that  values  stored  In  locations  not  mentioned  in  the 
modification  list  are  not  changed  during  the  course  of  the  computation.  This  is 
considerably  stronger  than  saying  that  the  values  of  unmemioned  places  are  the  same 
after  the  computation  as  they  are  at  the  beginning.  For  sequential  operation,  the  results 
are  the  same,  but  for  concurrent  operation  these  two  formulations  would  have  very 
different  consequences.  The  present  formulation  was  intended  to  lay  the  foundation  for 
the  concurrent  case,  so  the  stronger  statement  is  necessary.  There  are  instances,  however, 
where  the  actual  implementation  of  a program  involves  modification  of  a large  number 
of  places,  but  the  values  arc  re  s' or  cd  when  the  computation  terminates  Garbage 
collection  algorithms  and  operating  system  paging  routines  are  two  such  examples.  In 
our  present  formulation,  we  would  have  to  include  all  of  the  places  that  are  modified  in 
the  modification  Hst,  even  though  the  values  art  restored.  More  importantly,  we  would 
no  longer  benefit  from  the  implicit  preservation  of  the  state  information.  All  predicates 
related  to  any  of  the  modified  places  would  have  to  be  stated  and  reproven  to  hold. 
This  requirement  is  completely  contrary  to  our  philosophy  of  representing  Just  what  the 
program  knows  and  leaving  the  representation  of  the  state  Information  to  the  next 
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higher  level.  Moreover,  the  mechanisms  we  have  designed  are  strongly  dependent  on 
the  fact  that  values  are  not  touched.  To  extend  the  formalism  to  permit  values  to  be 
changed  but  restored  would  also  require  a substantial  change  In  the  proof  mechanisms. 

It  is  not  completely  dear  to  me  how  all  of  these  issues  should  be  resolved,  but  it  may  be 
necessary  to  provide  both  kinds  of  state  preservation.  Perhaps  a "restoration  list"  will 
have  to  be  added  to  SDs,  with  the  understanding  that  places  listed  on  the  restoration  list 
may  have  had  their  values  changed  but  that  their  values  are  restored  at  the  end  of  the 
computation  represented  by  the  SD.  Some  experimentation  is  necessary.^® 


6.2  Engineering  issues 


No  matter  how  the  theory  is  extended  to  handV  concurrency  and  multiple  processors, 
any  system  will  have  most  of  its  activity  modeled  as  a sequential  process.  The  present 
proof  system  is  extremely  clumsy  and  substantial  work  is  needed  to  bring  even  the 
present  theory  into  active  use. 

One  of  the  more  important  weaknesses  in  the  present  proof  system  is  the  lack  of 
mechanisms  to  represent  arrays.  Some  means  is  needed  to  enter  an  array  name  into  the 
place  system  and  declare  that  it  has,  say,  16,384  elements.  As  the  system  stands  now,  this 
would  have  to  be  entered  as  a family  in  the  place  system  with  16,384  daughters.  Since 
each  place  node  requires  about  8 Interlisp  cells,  the  overhead  for  this  representation  gets 
out  of  hand.  Not  all  of  this  overhead  can  be  avoided,  however.  Some  of  the  cells  In 
the  memory  array,  for  example,  need  to  be  represented  explicitly  because  predicates  are 
supported  by  the  contents  of  those  cells  and  not  others.  Most  of  the  cells  in  memory, 
however,  either  contain  pure  code  or  are  part  of  Bufferspace.  Individual 
representation  of  these  places  within  the  place  graph  is  unnecessary. 


Simulation  in  another  area  where  the  distinction  between  restoration  and  non- 
rnoilificalion  can  be  important,  if  an  abstract  machine  is  represented  as  having  a act  of 
disjoint  local  ions  and  a set  of  high-level  SDs  that  define  its  behavior,  then  it  is  not  possible  to 
implement  this  abstract  machine  with  a low  level  machine  that  modifies  but  restores  the  values 
of  the  simulated  disjoint  places.  As  a consequence,  some  reasonable  implementations  of 
abstract  machines  arc  prohibited.  There  is  one  payoff:  If  machine  C is  proven  to  be  a legal 
implementation  of  machine  A,  then  an  oseilloscopic  probe  may  he  place  on  the  implementation 
of  an  abstract  place  and  the  probe  will  be  active  only  when  the  abstract  SDs  predict  change  is 
possible.  If  we  intend  to  marry  the  notions  of  simulation  and  interconnection  of  processors,  we 
will  want  our  formalism  to  guarantee  that  the  suhsti  mion  of  a concrete  implementation  in 
place  of  an  ahstract  definition  will  not  change  the  opcrai  of  the  total  system. 
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Most  of  the  predicates  related  to  the  ;tate  of  the  machine  are  of  the  form  .X*v,  where  X 
is  a place  and  v is  a symbolic  value  that  is  not  dependent  upon  the  current  state.  Under 
these  circumstances,  it  seems  reasonable  to  streamline  the  representation  of  these 
predicates  by  allocating  a dedicated  cell  for  each  place  to  hold  its  current  value.  Such  a 
scheme  comes  much  closer  to  the  classical  symbolic  execution  model  and  should  have 
significant  impact  on  the  efficiency  of  the  system. 

A third  area  for  improvement  in  representation  is  the  SDs.  The  Honeywell  316  was 
modeled  as  having  a microprogram  counter.  The  role  of  the  microprogram  counter  is  to 
provide  a method  for  distinguishing  the  substates  within  the  execution  of  an  instruction. 
In  the  simple  model  used  in  the  main  example,  three  substates  are  needed.  In  the 
translation  of  the  full  316  description  from  ISPS,  a few  hundred  substates  are  needed! 
Similarly,  the  number  of  distinct  SDs  needed  for  a machine  description  is  fairly  large:  9 
for  the  simple  machine  and  310  for  the  full  machine.  In  the  specification  of  GFREE, 
the  notion  of  a compound  SD  was  introduced.  The  postcondition  of  a SD  contains 
another  SD.  This  idea  can  also  be  used  in  the  description  of  the  hardware.  Instead  of 
inventing  a name  for  the  intermediate  values  of  the  microprogram  counter,  it  is  possible 
to  tie  the  SDs  to  its  value  and  leave  the  value  unspecified.  Thus  the  only  facts  that 
need  be  known  about  the  value  of  the  microprogram  counter  are  which  SDs  are  valid. 
The  following  compound  SDs  could  have  been  used  to  represent  the  simple  version  of 
the  316. 


(Open  (pre?  (SD  fpre:  316pre) 

(mod: ) 

(env: ) 

(post:  (SO  (pre:  .PC*pc  .MEM. (.PC) *1400400) 

(mod:  Q PC  A) 

(env:  UPC) 

(post:  31Gpre  . PC^  (pc+1) ; 13  . A = f! ) 

(vars:  pc)) 

(SO  (pre:  .PC=pc  . MEM. ( . PC) *1010400) 

(mod:  □ PC) 

(env:  UPC) 

(post:  31Spre  (if  . A=0 

then  . PC* (pc+1 ) ; 13 
else  .PC* (pc+2) : 13) ) 

(vars:  pc)) 

(SO  (pre:  .MEM® ( .PC) ; 13, 10*0) 

(mod:  Q addrctrl) 

(env:  UPC) 

(post:  addrpre  (SD  (pre:  addrpost) 
(mod:  UPC) 

(env:  UPC  addrctrl) 
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(post:  316pre) 

(vars: ) ) 

•0P=.MEM- (.PC) ; 13, 10  . M;8=.MEM«  (.PC) 
; 8 (if  . Mf  Mo  (.PC)  <>9=0 
then  .M;13.9=0 
else  .Mj 13,3=. PC; 13,9) 

. I=.MEM°(.PC)  °15) 

(vars: ) ) ) 

(vars: ) ) 

(SO  (pre:  addrpre) 

(mod: ) 

(env: ) 

(post:  (SO  (pre:  .1=0) 

(mod:  UPC  actionctrl) 

(env:  UPC) 

(post:  actionpre  (SO  (pre:  actionpost} 

(mod:  UPC) 

(env:  UPC  actionctrl) 
(post:  addrpost) 

(vars: ) ) ) 

(vars: ) ) 

(SO  (pre:  addrpre  .1=1  . M=m) 

(mod:  UPC  I M) 

(env:  UPC) 

(post:  addrpre  . M=.MEM°m; i3  . 1 MEMom-15) 
(vars:  m))) 

(vars: ) ) 

(SO  (pre:  actionpre) 

(mod: ) 

(env:  UPC) 

(post:  (SO  (pre:  .0P=1  .M=m) 

(mod:  0 PC) 

(env:  UPC) 

(post:  actionpost  .PC=m) 

(vars:  m)) 

(SO  (pre:  .0P=4  .M=m  .PC=pc) 

(mod;  Q PC  MEM-m) 

(env:  UPC) 

(post:  actionpost  . PC«=  (pc+1 ) ; 1 3 .MEM°m«.A) 

( vars:  m pc) ) 

(SO  (pre:  .OP-10  .M=m  .MEM-m-v  .PC-pc) 

(mod:  0 PC  MEM-m) 

(env:  UPC) 
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(post:  actionpost  ,MEMom=(v+l)  ;1B 

(if  .Mtn-m-0 

then  (.POpc+2) ; 1 3 
else  .PC= (pc+1 ) ; 13) ) 

(vars:  m pc  v) ) 

(SD  (pre:  . 0P=1 1 .POpc  .A=a  ,M=m  .MEM»m>=b) 
(mod:  Q PC  A MEM «>m ) 

(env:  UPC) 

(post:  act  ionpost  .PC= (pc+1 ) ; 13  ,A«=b 
.HE(1otn=a) 

(vars:  pc  m a b) ) ) 

(vars: ) ) 

(Covering  OMEGA 

<addrctr I actionctrl  UPC  PC  MEM  M 1 A C 0P>) 
(Cover ing  MEM 

<MEM»277Q  MEM<>S00Q  MEM°10511Q  MEM"10512Q 
MEM-10S13Q  MEM°10S14Q  MEMol051BQ  MEM-1051GQ 
MEM»10517Q  MEM*>10S20Q  MEri'>i0b2iQ  riEM°10S22Q 


MEM-105230  BufferSpace  ZER0>)) 

(mod:  OMEGA) 

(env: ) 

(post: ) 

(vars: ) ) 

(NeuDecomposi t ion  (Covering  OMEGA 

<addrctr I actionctrl  UPC  PC  MEM  M 1 A C 0P>) 


) 

(NeuDecomposi t ion  (Covering  MEM 

<MEIW77Q  MEMo500Q  MEM"10511Q  MEMnl0512Q 
MEM»10513Q  MEM»1051AQ  MEM»10515Q 
MEM»1051GQ  MEM-10517Q  MEMol0520Q 
MEM»10521Q  MEM»10522Q  MEMol0523Q 


BufferSpace  ZER0>) ) 

(NeuComposi t ion  (Covering  Q <UPC  M I 0P>)) 


Only  three  SDs  exist  at  the  top  level.  These  stay  in  existence  permanently.  When  one 
of  them  is  activated,  it  may  bring  one  or  more  others  into  existence.  However, 
application  of  any  of  these  new  SDs  causes  all  of  the  new  SDs  to  be  deleted  from  the 
current  context,  although  others  may  be  added  as  the  result  of  the  application.  The 
number  of  compound  SDs  that  need  to  be  available  permanently  seems  to  be  based  on 
the  number  of  loops  in  the  machine  description,  for  the  full  316,  three  loops  exist  - the 
top  level,  the  shift  cycle  and  the  indirect  addressing  cycle  - so  the  310  SDs  could  be 
reduced  to  3 permanent  SDs  and  a small  handful  of  active  SDs  at  each  step. 


Reduction  of  the  number  of  SDs  makes  it  possible  to  build  a reasonable  proposer  to 
select  which  SD  to  apply  next.  Brute  force  testing  of  all  of  the  preconditions  is  not  even 
ruled  out,  but  more  sophisticated  schemes  may  be  possible.  Any  improvement  in  the 
proposer  will  have  a first-order  effect  on  the  size  of  the  proof. 

The  use  of  the  pattern  matcher  to  select  predicates  is  extraordinarily  expensive.  The 
pattern  matcher  we  are  using  compiles  its  patterns  when  they  are  first  encountered 
because  it  expects  to  use  them  repetitively.  We  use  our  patterns  exactly  once.  A large 
portion  of  the  execution  time  in  the  present  system  is  spent  converting  these  patterns  to 
executable  code.  The  space  consumed  by  the  translations  is  freed  up  after  it  is  used, 
and  a large  number  of  garbage  collections  are  needed  during  the  course  of  the  proof  to 
recover  this  space.  Finally,  the  patterns  are  used  to  search  the  whole  list  of  predicates 
accessible  in  the  current  context.  As  contexts  become  larger  and  larger,  this  strategy 
becomes  infeasible.  Some  means  to  refer  to  predicates  needs  to  be  found  which  does  not 
involve  searching  the  whole  context  and  which  docs  not  consume  and  discard  a lot  of 
space.  Predicates  are  already  cross-referenced  according  to  their  support,  and  this 
provides  at  least  one  useful  way  of  reaching  predicates  quickly.  Many  predicates  have 
no  support,  however,  and  perhaps  an  additional  cross-referencing  scheme  based  on  free 
variables  will  be  useful.  SDs  may  need  to  be  cross-referenced  according  to  the 
components  of  their  preconditions.  If  we  view  the  SDs  as  a set  of  productions,  cross- 
referencing  them  according  to  their  preconditions  provides  the  basis  for  a powerful 
control  mechanism  for  selecting  and  applying  the  right  SD  with  little  cost 2^ 


6.3  Prognosis 

If  we  look  forward  to  a time  when  verification  is  an  accepted  practice  and  the 
programmer  submits  his  program  to  a verifier  with  the  same  regularity  that  he  now 
submits  it  to  a compiler  or  assembler,  three  perceptions  emerge.  First,  the  verification 
must  be  completely  automatic  and  deterministic.  Second,  the  verifier  must  process 
between  ten  and  one  hundred  statements  per  second.**0  Third,  the  proof  may  not  be 
much  longer  than  the  program  but  need  not  be  much  shorter. 


20  Kandall  Davis  and  Jonathan  King,  "An  Overview  of  Production  Systems,1’  Computer 
Science  Dcparimenl,  Stanford  University,  California,  STAN-CS-75-524,  October  1975. 

**°  I am  indebted  to  Mac  McKinley  for  posing  the  question  of  how  long  it  would  take  to 
do  a full  verification. 


112 


Requiring  the  verifier  to  operate  automatically  It  quite  distinct  from  the  lstue  of 
development  of  the  proof  interactively.  I believe  that  development  of  the  proof  is  very 
likely  to  be  an  interactive  process  and  be  comparable  in  style  to  the  use  of  an  editor. 
Once  complete  however  the  program  and  its  proof  will  be  assembled  or  compiled  tt> 
executable  code  and  at  the  same  time  verified  for  correctness.  Programmers  generally 
expect  compilation  errors  only  if  they  mistype.  Compilers  which  are  very  poorly 
documented,  in  a state  of  transition  or  syntactically  arcane  provide  the  alternate  surprise 
that  the  program  may  look  correct  even  upon  close  inspection  but  may  fail  to  compile 
because  the  compiler  doesn’t  work  as  expected.  Such  compilers  are  held  in  low  esteem 
and  in  practice  do  not  survive  long.  I expect  verification  systems  to  live  within  the 
same  constraints,  and  thus  programmers  will  expect  to  be  able  to  write  correct  proofs 
with  a high  degree  of  confidence  and  have  these  proofs  be  accepted  with  the  same 
success  that  source  code  passes  the  syntax  checker.  Wegbreit’s  recent  work  looks  very 
promising  along  this  line.^1 

Clven  that  we  accept  the  need  for  the  verifier  to  be  automatic,  ve  can  further  look  at 
the  effect  of  how  the  speed  of  the  verification  system  will  affect  its  use.  In  our  present 
environment  assembly  of  a large  program  (eg.  the  TENEX  operating  system)  requires 
approximately  an  hour  to  assemble  a quarter  million  instructions.  Full  assemblies  are 
done  Infrequently  but  probably  as  often  as  once  a day  as  a new  version  of  the  system 
nears  completion  or  is  assembled  with  local  parameters  for  particularization  to  a site. 
Smaller  programs,  say  ten  thousand  instructions,  require  a couple  of  minutes  and  a user 
will  reassemble  at  ah, lost  every  convenient  juncture.  If  we  intend  that  verification  of  a 
program  fit  into  this  mold  and  thus  bring  a milieu  in  which  programs  are  checked  for 
consistency  with  theii  specifications  as  naturally  as  they  are  checked  for  correct  syntax, 
then  the  verification  system  will  have  to  perform  at  comparable  speeds,  say  close  to  100 
instructions  per  second.  Performance  in  the  range  of  10  Instructions  per  second  means 
that  a user  will  reverify  a 10,000  instruction  program  using  an  overnight  batch  service 
and  will  tolerate  more  frequent  verification  only  for  programs  up  to  1000  words.  These 
numbers  are  comparable  to  the  performance  levels  of  poor  compilers  in  the  1 960’s  or 
earlier  and  may  weh  iie  within  the  tolerable  range  for  consistent  use.  However,  the 
increased  cost  and  delay  will  need  to  be  offset  by  demonstrated  payoff  in  the  location  of 
bugs  or  by  management  edict. 


Performance  in  the  range  of  one  statement  per  second  is  likely  to  inhibit  wholesale 
adoption  of  verification  as  a production  tool  and  restrict  its  use  to  experimental 
programming  groups  and  selected  critical  system  development  efforts. 


'll 

* Ben  Wegbrcit,  "Constructive  Methods  in  Propram  Verification,”  IEEE  Transactions 
on  Software  Engineering,  Vol.  SK-3,  No.  3,  May  1977,  pp.  193-209. 
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I have  not  begun  to  perform  detailed  measurements,  nor  is  it  entirely  meaningful  to  do 
so  at  this  time.  At  present  the  proofs  are  so  laborious  that  even  an  infinitely  fast 
verifier  would  not  be  attractive  enough  to  overcome  the  excessive  labor  required  to 
prepare  the  proof.  These  caveats  aside,  1 believe  the  current  system  verifies  between 
one-tenth  and  one  statement  per  second  and  is  thus  acceptable  as  an  experimental 
vehicle  but  unacceptable  as  a production  tool. 

With  respect  to  the  size  of  the  proof,  we  can  use  the  same  kind  of  "impedance  match" 
argument  that  the  proof  must  not  be  too  much  longer  than  the  program.  Long  proofs 
require  more  labor  by  the  programmer  and  will  be  avoided.  Proofs  that  do  not 
materially  change  the  coding  time  are  thus  required  for  regular  use.  Again  Wegbreit’s 
recent  work  suggests  this  goal  is  attainable  without  substantial  difficulty.  Our  present 
system  is  well  short  of  the  mark.  Our  first  proof  was  nine  pages  long  for  a nine 
instruction  program  and  is  further  embarrassed  by  the  presence  of  unchecked  user- 
supplied  ellisions  in  the  reasoning  chain.  A ratio  of  50  to  one  is  laughably 
unacceptable,  but  is  not  much  cause  for  worry;  ideas  for  automating  the  proof  system 
and  compressing  the  proof  are  flowing  so  rapidly  that  the  only  role  of  the  present 
statistic  is  to  set  the  stage  for  spectacular  claims  of  improvement  in  the  future. 
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